| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were multiple problems with incremental mode and partitionable
arrays. Change the logic to pay more attention to what it finds in
mdadm.conf when setting up incremental arrays. Modify is_standard to
differentiate between a required partitioned name format and an optionally
partitioned named format. Modify open_mddev() to know about change to
is_standard. Make Incremental differentiate between create default
autof setting, command line autof setting, and array specific autof
setting, with order of preference being command line, conf file, default.
Disable the homehost test in the event there is no match for an array
so we can hotplug new arrays into a running machine without them having
to exist in mdadm.conf first (a random array number will be picked for
the hot plugged array). Honor any name from mdadm.conf that matches the
UUID of a device, not just standard names. Verify that the array name
as matched in mdadm.conf allows the requested mode of operation and reject
attempts to start non-partitionable arrays as partitioned and vice versa.
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
RAID10 is the only raid level that uses the avail char array pointer
during the enough() operation, so it was the only one that saw this.
The code in incremental assumes unconditionally that count_active will
allocate the avail char array, that it might be used by enough, and that
it will need to be freed afterward. Once you make count_active actually
do that, then the oops goes away.
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
Certain operations (Detail.c mainly) would print out the metadata of
an array in a format that the scan operation in super0.c and super1.c
would later reject as unknown when it was found in the mdadm.conf file.
Use a consistent format, but also modify the super0 and super1 match
methods to accept the other format without complaint.
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
|\ |
|
| |
| |
| |
| | |
Special point release for Debian-Lenny
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When adding a device to an array, we check that it is large enough.
Currently the check makes sure there is also room for a reasonably
sized bitmap. But if the array doesn't have a bitmap, then this test
might be too restrictive.
So when adding, only insist there is enough space for the current
bitmap.
When Creating, still require room for the standard sized bitmap.
This resolved Debian Bug 500309
|
| |
| |
| |
| |
| |
| |
| | |
We are loading into the already-loaded 'st' instead of the
newly create 'tst', which is clearly wrong.
Resolves Debian Bugs 496334/499643/498505
|
| |
| |
| |
| | |
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
| |
| |
| |
| |
| |
| | |
structure
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
|/
|
|
| |
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
Since we made free_super a superswitch call, we need to be careful
that st is non NULL before calling st->ss->free_super(st).
Also when updating byteorder there is a chance of a similar NULL
deref.
|
|
|
|
| |
Causes compile error with gcc-2.95
|
|
|
|
|
|
|
|
| |
If you have stacked arrays, then
mdadm -As --homehost=fred
should work but doesn't. It gets into an infinite loop!
So write some tests, and fix the bugs.
|
| |
|
|
|
|
|
|
| |
From: David Greaves <david@dgreaves.com>
Signed-off-by: David Greaves <david@dgreaves.com>
|
|
|
|
| |
and tidy up Makefile a bit.
|
|
|
|
|
|
|
| |
This is
make MDASSEMBLE_AUTO=1 mdassemble.static
so we now find compile bugs more easily.
|
| |
|
| |
|
| |
|
|
|
|
| |
....as this cannot work.
|
|
|
|
| |
The user of dup_super broke it.
|
|
|
|
|
| |
In particular, failing a device would give a silly
error message.
|
| |
|
|
|
|
|
| |
If the first device we look at has no superblock,
there is no 'st' to free, so don't free it.
|
|
|
|
| |
From: Hans Lambermont <hans.lambermont@newtec.eu>
|
|
|
|
|
|
|
| |
From: Kay Sievers <kay.sievers@vrfy.org>
Cc: David Zeuthen <david@fubar.dk>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
|
| |
|
|
|
|
|
|
| |
From: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
|
|
|
| |
Two places have code to find a free md device number. Make this
a subroutine.
|
|
|
|
|
|
| |
From: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From: Bill Nottingham <notting@redhat.com>
mdadm --incremental doesn't really do any locking. If you get multiple
events in parallel for the same device (that has not yet started), they
will all go down the path to create the array. One will succeed, the
rest will have SET_ARRAY_INFO die with -EBUSY (md: array mdX already has disks!)
and will exit without adding the disk.
Original bug report is: https://bugzilla.redhat.com/show_bug.cgi?id=433932
This is solved by adding very very rudimentary locking. Incremental() now
opens the device with O_EXCL to ensure only one invocation is frobbing the
array at once. A simple loop just tries to open 5 times a second for 5
seconds. If the array stays locked that long, you probably have bigger
issues.
|
|
|
|
| |
From: Bill Nottingham <notting@redhat.com>
|
|
|
|
| |
The 'D' in 'RAID' stands for 'DISKS' even it md supports other 'devices'.
|
| |
|
|
|
|
| |
Debian bug 477273
|
| |
|
|
|
|
|
| |
When adding a device to an array, make sure we don't reserve
so much space for the bitmap that there isn't room for the data.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|