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>
Neil Brown
maximilian attems
Doug Ledford