| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| | |
Conflicts:
Manage.c
|
| |
| |
| |
| |
| |
| | |
If we add a device to a linear array which is a difference size
to the other devices in the array then, for v1.x metadata, we need to
make sure the size is correctly reflected in the superblock.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Showing e.g.
near=1, far=2
for the 'far2' layout of raid10 is confusing even though there is a
sense in which is it correct.
Make it less confusing by only printing whichever number is not 1.
If both are 1, make that clear too (i.e. no redundancy).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Made the mistake of recompiling the F9 mdadm rpm which has a patch to
remove -Werror and add "-Wp,-D_FORTIFY_SOURCE -O2" which turns on lots
of errors:
config.c:568: warning: ignoring return value of asprintf
Assemble.c:411: warning: ignoring return value of asprintf
Assemble.c:413: warning: ignoring return value of asprintf
super0.c:549: warning: ignoring return value of posix_memalign
super0.c:742: warning: ignoring return value of posix_memalign
super0.c:812: warning: ignoring return value of posix_memalign
super1.c:692: warning: ignoring return value of posix_memalign
super1.c:1039: warning: ignoring return value of posix_memalign
super1.c:1155: warning: ignoring return value of posix_memalign
super-ddf.c:508: warning: ignoring return value of posix_memalign
super-ddf.c:645: warning: ignoring return value of posix_memalign
super-ddf.c:696: warning: ignoring return value of posix_memalign
super-ddf.c:715: warning: ignoring return value of posix_memalign
super-ddf.c:1476: warning: ignoring return value of posix_memalign
super-ddf.c:1603: warning: ignoring return value of posix_memalign
super-ddf.c:1614: warning: ignoring return value of posix_memalign
super-ddf.c:1842: warning: ignoring return value of posix_memalign
super-ddf.c:2013: warning: ignoring return value of posix_memalign
super-ddf.c:2140: warning: ignoring return value of write
super-ddf.c:2143: warning: ignoring return value of write
super-ddf.c:2147: warning: ignoring return value of write
super-ddf.c:2150: warning: ignoring return value of write
super-ddf.c:2162: warning: ignoring return value of write
super-ddf.c:2169: warning: ignoring return value of write
super-ddf.c:2172: warning: ignoring return value of write
super-ddf.c:2176: warning: ignoring return value of write
super-ddf.c:2181: warning: ignoring return value of write
super-ddf.c:2686: warning: ignoring return value of posix_memalign
super-ddf.c:2690: warning: ignoring return value of write
super-ddf.c:3070: warning: ignoring return value of posix_memalign
super-ddf.c:3254: warning: ignoring return value of posix_memalign
bitmap.c:128: warning: ignoring return value of posix_memalign
mdmon.c:94: warning: ignoring return value of write
mdmon.c:221: warning: ignoring return value of pipe
mdmon.c:327: warning: ignoring return value of write
mdmon.c:330: warning: ignoring return value of chdir
mdmon.c:335: warning: ignoring return value of dup
monitor.c:415: warning: rv may be used uninitialized in this function
...some of these like the write() ones are not so trivial so save those
fixes for the next patch.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
| |
| |
| |
| |
| |
| | |
As we need to be able to extract a UUID from any superblock
for matching, use that as the MD_UUID as it will probably be
used for array matching too.
|
| |
| |
| |
| | |
--detail sometimes generates leading zero which are just noise.
|
| |
| |
| |
| | |
Now 'make everything' works again.
|
| |
| |
| |
| | |
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Using buffered IO risks non-atomic updates to parts of the
device that we don't actually want to write to. This isn't in
general safe.
So switch to O_DIRECT for all that IO and make sure we have
properly aligned buffers.
|
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Using write_init_super to add a spare to an active array is quite
different to how it is used when creating an array.
It mostly works, but if we are adding two devices to an array,
then when we add the second, there are still traces of the first
which confuse write_init_super.
So get write_init_super to ignore those traces. Longer term, we
probably want to do this differently as for DDF, hot-adding to
an active array will have to be quite different - it will want to
write to all metadata, possibly via mdmon.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
| |
These will be used for ddf.
|
|
|
|
|
|
|
| |
From: Kay Sievers <kay.sievers@vrfy.org>
Cc: David Zeuthen <david@fubar.dk>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
|
|
|
|
|
| |
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.
|
|
|
|
| |
It is now in the 'supertype'
|
|
|
|
|
| |
As this function takes 2 superblocks, the change is a bit more subtle,
so is done separately.
|
|
|
|
| |
The 'superblock' will be moved into this structure soon.
|
|
|
|
|
|
| |
As the metadata handler allocates the superblock, it should free it
too. DDF will have a more complex 'superblock' which needs more complex
freeing.
|
|
|
|
|
| |
Not all of the device may be available. Of that, not all may be used
(if devices are of different sizes).
|
| |
|
|
|
|
|
|
|
|
| |
Commit a40b4fe introduced a temporary supertype variable tst, instead of
manipulating st directly. However, it was forgotton to pass &tst into the
recursive load_super1 call, causing an infinite recursion.
Signed-off-by: martin f. krafft <madduck@debian.org>
|
|
|
|
|
|
|
|
| |
When load_super1 is trying to see which sub-version of v1 superblock
is present, failure will cause it to clear st->ss, which is not good.
So use a temporary 'super_type' for the 'test if this version works'
calls, then copy that into 'st' on success.
|
|
|
|
|
|
| |
When adding new disk to an array, don't reserve so much bitmap
space that the disk cannot store the required data. (Needed when
1.x array was created with older mdadm).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From: Doug Ledford <dledford@redhat.com>
OK, this one fixes an issue where people were doing manual array
creation and specifying superblock types other than 1.0 (aka, 1.1, 1.2)
and then using mdadm -Ebs to populate their mdadm.conf file. The
general problem is that if you specify a superblock type in the ARRAY
line (or on the command line), then you must specify the superblock type
*exactly*, including the minor version. Unfortunately, mdadm -Ebs
prints out all version 1 superblocks, regardless of minor version, as
just plain old 1. This breaks the mdadm.conf file for anything other
than plain version 1 superblock devices.
So, since I thought it was basically backwards that the mdadm -E output
was lax on specifying the location of the superblock where as the mdadm
-A input was strict, I reversed that. With this patch, the mdadm -E
output is now exact for any given superblock. But, in addition, the
mdadm -A input is now lax for any superblock that doesn't specifically
list the minor version, aka version 1 now means version 1, not version
0.90, but any minor version. So does default/large.
|
|
|
|
|
|
| |
Update the testing scripts to allow for new space calculations
for space for bitmaps.
Add a test script for adding devices to linear arrays.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
The bitmap offset is a signed 32bit number, so casting to (long)
isn't sufficient. We must cast to (int32_t).
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
We have the same calculation in multiple places with subtle differences.
So unite it all.
Also fix up and endian problem in --examine.
|
| |
|
|
|
|
|
| |
The case that doesn't initialise it is impossible,
so just return with an error..
|
|
|
|
| |
Rather than opencoding the byteswap all the time.
|
| |
|
|
|
|
| |
Only happens on kernel with 32 bit sector_t.
|
|
|
|
| |
Instead of opencoding the same thing everywhere.
|
|
|
|
| |
A number of odd bugs here, but now we have a regression test as well.
|
|
|
|
|
| |
This doesn't get mailed out, but will appear in syslog...
Maybe it should be mailed if it was a 'check' or 'repair' pass...
|
|
|
|
|
| |
because it only shows how much of each device is actually used, not
how big they are.
|
|
|
|
| |
and is also degraded.
|
| |
|
|
|
|
| |
size.
|
|
|
|
|
|
|
|
|
|
| |
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.
|