There is still a problem: If array is partially assembled and started
read-only, the last device doesn't get added properly. Probably a kernel
problem.
The new superblock needs to have a new disk.number. This is a bit of a hack...
Fix handling of negative bitmap offsets on 64bit hosts.
The bitmap offset is a signed 32bit number, so casting to (long)
isn't sufficient. We must cast to (int32_t).
Fix various problems with --grow --add for linear.
The code to add a drive to a live linear array had never
been tested properly and so was buggy. This tidies it up
and means that the new regression-test passes.
udev likes to get information about a device as key=value pairs so it
can create disk/by-id links etc. So add --export flag which causes
the output of --detail to easily parsable.
From: Kay Sievers <kay.sievers@novell.com>
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.
It is much better for this sort of thing to be predictable
rather than depending on what devices exist, especially as
these days entries in /dev/ often don't pre-exist.
So make it always
/dev/mdX
for version0 superblocks.
Version1 are always /dev/md/NAME
Make -assemble a bit more resilient to finding strange
information in superblocks.
Don't claim newly added spares are InSync!! (don't know why that
code was ever in there)
Apparently there are license issues with openssl, so
just use sha1.c always. This means we can get rid of
SHA1.c
Signed-off-by: Neil Brown <neilb@suse.de>
From: Luca Berra <bluca@vodka.it>
glibc 2.4 is pedantic on ignoring return values from fprintf, fwrite and
write, so now we check the rval and actually do something with it.
in the Grow.c case i only print a warning, since i don't think we can do
anything in case we fail invalidating those superblocks (is should never
happen, but then...)
Signed-off-by: Neil Brown <neilb@suse.de>
This cannot be used yet, but it is working towards auto-assembly.
When auto-assembling an array, we make a name in /dev/md/
giving a number (from the peferred minor) or name (from set-name).
Signed-off-by: Neil Brown <neilb@suse.de>
i.e. if assembling with --name or --super-minor, then if we find two
different arrays with the same apparent identity, and one was built
for 'this' host, then prefer that one instead of giving up in disgust.
Signed-off-by: Neil Brown <neilb@suse.de>
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>
For 'force' and 'assemble', update_super must return true
if anything was changed.
Also fix a bug with wonly handling in super0.
Signed-off-by: Neil Brown <neilb@suse.de>
### Diffstat output
./super0.c | 18 ++++++++++++++----
./super1.c | 7 +++++++
2 files changed, 21 insertions(+), 4 deletions(-)
diff ./super0.c~current~ ./super0.c
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>
Neil Brown
Kay Sievers
Kay Sievers