| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
Replace occurrences of ~0ULL to make it clear we are talking about maximal
resync/recovery position.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|/
|
|
|
|
|
| |
When creating an array, check if the devices have partition
tables and print a warning if the table or the partitions might be
destroyed by array creation.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
|
| |
As a some/most bootloaders don't understand md metadata, it might
be difficult to boot off an array with the default 1.0 metadata.
So if this is used for a RAID1, ask for confirmation.
Signed-Off-By: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
|
|
| |
->validate_geometry is called to validate overall parameters,
and to validate each individual device.
If it ever fails, it needs to report the reason, as common code
cannot possible know.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
|
|
|
|
| |
This seems more appropriate for current (and recent) model drives than
64K.
64K is still the default for '--build' as changing that could corrupt
data.
64K is also the default rounding for 'linear' on kernels older than
2.6.16.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The map file needs to be updated after adding the first member array to
an Intel metadata container. The uuid for an imsm container uses the
->family_num field of the metadata. This field is static, but is only
set after the first member array has been created. Prior to this all
devices are free floating spares and do not have any information that
can identify specific container membership. At Create() time we take
the uninitialized uuid from ->get_info_super() prior to updating the
metadata. So the current result is:
# mdadm --create /dev/md/imsm /dev/sd[b-e] -n 4 -e imsm
# mdadm --create /dev/md/vol0 /dev/md/imsm -n 4 -l 0
# cat /var/run/mdadm/map
md126 /md127/0 3e03aee2:78c3c593:1e8ecaf0:eefb53ed /dev/md/vol0
md127 imsm 53d6f8b1:7a783f24:f30483c5:705c48c7 /dev/md/imsm
# mdadm -Ebs
ARRAY metadata=imsm UUID=589d2d2c:4221a54d:acb63c06:c3907f52
ARRAY /dev/md/vol0 container=589d2d2c:4221a54d:acb63c06:c3907f52
member=0 UUID=57b89b63:5cd0eae1:17dd26b3:51cc78d4
So, before we write out the new metadata check to see if the member
array uuid has changed as a result of this addition. If it has, update
its uuid in the map file and flag its parent container for updating. In
support of updating the container uuid the semantics of
->write_init_super are changed to clear any metadata specific member
array cursors (e.g. ddf_super.currentconf or intel_super.current_vol)
such that a subsequent call to ->getinfo_super returns container
information.
Reported-by: Ignacy Kasperowicz <ignacy.kasperowicz@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
|
|
|
|
| |
Also removed 'paper' addresses.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
|
| |
wait not only for the name to appear, but for it to refer to the
correct device.
Sometimes old symlinks left lying around can be confusing.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
| |
There are probably other places where rounding size to
chunksize is needed, or useful, but this is a good start.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
|
|
| |
'subdevs' is read from the container in the auto-layout case so reset
subdevs dependent default values. 'insert_point' without this
change is always 2 blocking creation of arrays with > 2 raid disks.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
|
|
|
| |
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the metadata handler can not find its platform support components
then there is no way for it to verify that the raid configuration will
be supported by the option-rom. Provide a generic method for metadata
handlers to warn the user that the array they are about to create may
not work as intended with a given platform.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
|
|
|
|
|
|
| |
Let handlers specifiy their own defaults, specifically needed for the
imsm-raid5 case where mdadm defaults to 'ls' and imsm to 'la'.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
|
|
|
|
|
|
|
| |
If, when creating an array, a signal target device is given which
is a container, then allow the metadata handler to choose which
devices to use.
This is currently only supported for DDF.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
| |
That way it is the same a *freesize, and generally less confusing.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
|
| |
We currently print e.g. "Array /dev/md0 started", but nothing for
containers.
Fix that.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
| |
Make sure every failure from add_to_super prints a suitable
error message, and then don't print any error in the caller.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
| |
Prepare add_to_super to validate disks against the platform capabilities
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
|
|
|
|
|
| |
Otherwise we get an unpleasant 2 second pause when array creation
fails.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
| |
We don't really want mdadm to exit until udev has
created the names in /dev. So wait.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
| |
As with Assemble, one create_mddev has chosen a name, we should always
use that rather than the passed 'mddev'.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
|
| |
As spares are treated quite differently in containers, we cannot
fake-up a spare to optimise initialisation for a raid5 in a container,
so disable that code for ->external arrays.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
| |
Thus an auto-generated config file will list all the arrays.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
| |
In two devices are added via -I to one array at the same time, mdadm
can get badly confused.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
|
|
|
|
| |
When a 'container' gets started, we need udev to notice, but the
kernel has no way of knowing that a KOBJ_CHANGE event is needed. So
send one directly via the 'uevent' sysfs attribute.
Also, uevents don't get generated when md arrays are stopped (prior to
2.6.28) so send 'change' events then too.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
|
| |
We previously only updated /var/run/mdadm/map when starting an
array with --incremental. However we now make more use of
that file (to pass the dev name to udev) so always update it.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
| |
MORE CONTENT HERE
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We will shortly be feeding more information into the process of
creating array devices, so delay the creation. Still open them
early if the device already exists.
This involves making sure the autof flag is in the right place
so that it can be found at creation time.
Also, Assemble, Build, and Create now always close 'mdfd'.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
Create.c
Manage.c
|
| |
| |
| |
| |
| |
| |
| |
| | |
Previously it was possible to set the WRITEMOSTLY flag when
adding a device to an array, but not to clear the flag when re-adding.
This is now possible with --readwrite.
Signed-off-by: NeilBrown <neilb@suse.de>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It is meaningless when creating the container, and for
subarrays, the container is responsible for assigning
spares.
Also, don't do the 'spare' fiddle for raid5 as we cannot
set up a spare at this point yet. Later maybe just create
the array degraded and let the container sort it out.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we assemble an array, there are three different approaches
depending on whether metadata is internal or external, and on
kernel version.
Move all this to a common helper instead of duplicating in 3 places.
Signed-off-by: NeilBrown <neilb@suse.de>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The variety of approaches to 'add_disk' are factored out into
a separate function, and Incremental mode benefits by being
closer to supporting the assembly of containers.
Also remove the adding-to-array-data-structure out of sysfs_add_disk
and into add_disk.
And add some tests for --incremental mode to make sure we don't break it.
Signed-off-by: NeilBrown <neilb@suse.de>
|
| |
| |
| |
| | |
Now 'make everything' works again.
|
| |
| |
| |
| | |
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
| |
| |
| |
| |
| |
| |
| | |
We are about to change the syntax of the version string
for 'subarray's. So factor out the test into a single function.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
Create.c
Manage.c
|
| |
| |
| |
| |
| |
| |
| |
| | |
Fix on call that passed an invalid mode to open
Don't pass a third arg unless we also pass O_CREAT
Use symbolic args for 2nd and 3rd args
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Neil Brown <neilb@suse.de>
|
| |
| |
| |
| | |
Signed-off-by: Neil Brown <neilb@suse.de>
|
| |
| |
| |
| |
| |
| | |
Useful for attaching gdb to mdmon before any action is taken on the array.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
| |
| |
| |
| |
| |
| |
| | |
When creating an array in a container, print e.g.
Creating array inside ddf container /dev/whatever
rather than
Defaulting to version /md127/1 metadata
|
| |
| |
| |
| |
| | |
That way it can be silent when we are just trying to figure out
which metadata to use, and noisy when detecting a real problem.
|
| |
| |
| |
| |
| | |
Support creating arrays inside an active ddf container by
sending a metadata update over a pipe to mdmon.
|
| |
| |
| |
| | |
Use 'info pointer is NULL' instead.
|
| |
| |
| |
| |
| | |
Getting close to a sensible description of what some of the
superswitch methods are supposed to do!
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When loading the metadata for a subarray (super_by_fd), we set
->subarray to be the name read from md/metadata_version so that
getinfo_super can return info about the correct array.
With this we can differentiate between a container and
an array within the container by looking at ->subarray[0].
|
| |
| |
| |
| | |
It isn't generally meaningful.
|
| |
| |
| |
| |
| |
| | |
For arrays that don't have redundancy (raid0, linear etc), the
clean/dirty distinction doesn't mean anything. So always
'assume clean' for these arrays.
|