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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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].
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.
'container_member' isn't really a well defined concept.
Each metadata might enumerate members differently, so just
let each format /mdX/YYYY as appropriate.
I want the metadata handler to have more control over the 'version',
particularly for arrays which are members of containers.
So discard st->text_version and instead use info->text_version
which getinfo_super can initialise.
From: Dan Williams <dan.j.williams@intel.com>
This should probably be made into a generic 'external' capability rather
than hardcoding 'ddf' and 'imsm'.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Create a ddf array by naming the device /dev/ddf* or
specifying metadata 'ddf'.
If ddf is specified with no level, assume a container (indeed,
anything else would be wrong).
**Need to use text_Version to set external metadata...
More ddf support
Load a ddf container. Now
--examine /dev/ddf
works.
super-ddf: fix compile warning
From: Dan Williams <dan.j.williams@intel.com>
super-ddf.c:723: format %lu expects type long unsigned int, but argument 3 has type unsigned int
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The current model for creating arrays involves writing
a superblock to each device in the array.
With containers (as with DDF), that model doesn't work.
Every device in the container may need to be updated
for an array made from just some the devices in a container.
So instead of calling write_init_super for each device,
we call it once for the array and have it iterate over
all the devices in the array.
To help with this, ->add_to_super now passes in an 'fd' and name for
the device. These get saved for use by write_init_super. So
add_to_super takes ownership of the fd, and write_init_super will
close it.
This information is stored in the new 'info' field of supertype.
As part of this, write_init_super now removes any old traces of raid
metadata rather than doing this in common code.
Now that validate_geometry opens and checks the device,
we don't need to do it as much in top level Create.
We only need it to check for old array or filesystem info.
So only open the device at that place.
This did not work before as we couldn't mark it clean as there would
be some parity blocks out of sync, and raid6 will not assemble a
dirty degraded array.
So make such arrays doubly degraded (the last device becomes a spare)
and clean.
From: Doug Ledford <dledford@redhat.com>
This one actually does a couple things. Mainly related to raid4, but
kinda touches other raid levels some.
When creating a raid4 array, treat it like a raid5 array in that we
create it in degraded mode by default and add the last disk as a spare.
Besides speeding things up, this has a second effect that it makes mdadm
more consistent. In order to create a degraded raid5 array, you need
only passing missing as one of the devices. For a degraded raid4 array,
prior to this patch, you must pass assume-clean or else it refuses to
create the array. Even force won't make it work without assume-clean.
With the patch, raid4 behaves identical to raid5.
Separate from that, the monitor functionality completely ignores raid4
arrays. That seems to stem from the code that checks to see if the
array is part of a long list of types. It seems easier to check which
array types *aren't* redundant instead of listing the ones that are
redundant and missing some of them. This makes the monitor service
actually watch raid4 arrays.
From: Doug Ledford <dledford@redhat.com>
Simple bugfix. If an array already exists and we are asked to create
this array, error out with an error message that makes sense to people
instead of an error that the SET_ARRAY_INFO ioctl had an invalid
argument. Plus a typo correction.
Depending on the size of the array we reserve space for up to 128K
of bitmap, and we use it where possible.
When hot-adding to a version 1.0 we can still only use the 3K at the
end though - need a sysfs interface to improve that.
If a small chunksize is requested on Create, we don't auto-enlarge
the reserved space - this still needs to be fixed.
When an array is created, if the homehost is know,
the superblock gets it, either in the uuid, (via sha1)
or in the name field.
Signed-off-by: Neil Brown <neilb@suse.de>
When creating a file bitmap, choose a default size that
results in fewer than 2^21 chunks. Without this kmalloc
failure in the kernel becomes likely.
Signed-off-by: Neil Brown <neilb@suse.de>
clean up 'long long' usage for size of array, so that
with v-1 superblocks a raid1 larger than 2TB is possible.
Signed-off-by: Neil Brown <neilb@suse.de>
Currently this includes
--write-behind to set level of write-behind supported
--write-mostly to flag devices as write-mostly.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
This includes:
adding --metadata= option to choose metadata format
adding metadata= word to config file.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
This allows for larger device number if glibc supports
it (requires 2.3.3).
Also fail before creating larger device number if glibc
support isn't present.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
NeilBrown
Dan Williams
Doug Ledford
maximilian attems