This allows the metadata on a device to be saved and later restored.
This can be useful before experimenting on an array that is misbehaving.
Suggested-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
We widely use a "devnum" which is 0 or +ve for md%d devices
and -ve for md_d%d devices.
But I want to be able to use md_%s device names.
So get rid of devnum (a number) and use devnm (a 32char string).
eg.
md0
md_d2
md_home
Signed-off-by: NeilBrown <neilb@suse.de>
Commit 1e2b276535 (Report error in --update
string is not recognised) broke homehost updating functionality because it
depended on each string comparison being done even after we already found
a match. Make it work again by restructuring code.
Reported-by: (and original version by) Justin Maggard <jmaggard10@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Now that we use O_DIRECT for all device IO, BLKFLSBUF is not needed to
ensure we get current data, and it can impose a cost if any flush-out
is needed. So remove it.
To be safe, add O_DIRECT to one place where it isn't currently used:
when reading a bitmap.
Signed-off-by: NeilBrown <neilb@suse.de>
--detail needs to be read to report 2 devices in each slot,
and --examine need to report if the device is the original or
the replacement.
Signed-off-by: NeilBrown <neilb@suse.de>
mdadm --create /dev/md0 .... /dev/sda1:1024 /dev/sdb1:2048 ...
The size is in K unless a suffix: K M G is given.
The suffix 's' means sectors.
Signed-off-by: NeilBrown <neilb@suse.de>
sometimes 0.1% isn't enough, though mostly only in testing.
We need one chunk for a successful reshape, so reserve 2.
Signed-off-by: NeilBrown <neilb@suse.de>
Some arrays (raid10) never need a backup file, so during assembly
we can avoid the whole Grow_continue check in that case.
Achieve this using a flag set by the metadata handler.
Also get "mdadm -I" to fail if a backup process would be
needed. It currently does fail as the kernel rejects things,
but it is nicer to have this explicit.
Signed-off-by: NeilBrown <neilb@suse.de>
The 'new_offset' is used for reshaping to avoid the need
for a backup file.
For now we only report the value when it is set.
Signed-off-by: NeilBrown <neilb@suse.de>
This is currently only useful for 1.x metadata and will allow an
explicit --data-offset request on command line.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ When printing the "name=" entry for --brief output,
enclose name in quotes if it contains spaces etc.
Quotes are already supported for reading mdadm.conf
2/ When a name is used as a device name, translate spaces
and tabs to '_', as well as the current translation of
'/' to '-'.
Signed-off-by: NeilBrown <neilb@suse.de>
--update=bbl will add a bad block list to each device.
--update=no-bblk will remove the bad block list providing that it
is empty.
Signed-off-by: NeilBrown <neilb@suse.de>
An additional pair of key=value for --examine --export.
Signed-off-by: Maciej Naruszewicz <maciej.naruszewicz@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If we change some functions to accept 'verbose', where <0 means to be
quiet, in place of 'quiet', then we will be able to merge
'quiet' and 'verbose' together for simplicity.
Signed-off-by: NeilBrown <neilb@suse.de>
malloc should never fail, and if it does it is unlikely
that anything else useful can be done. Best approach is to
abort and let some super-daemon restart.
So define xmalloc, xcalloc, xrealloc, xstrdup which don't
fail but just print a message and exit. Then use those
removing all the tests for failure.
Also replace all "malloc;memset" sequences with 'xcalloc'.
Signed-off-by: NeilBrown <neilb@suse.de>
In function write_init_super1():
If "rv = store_super1(st, di->fd)" return error and the di is the last.
Then the di = NULL && rv > 0, so exec:
if (rv)
fprintf(stderr, Name ": Failed to write metadata to%s\n",
di->devname);
will be segmentation fault.
Signed-off-by: majianpeng <majianpeng@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
While it is nice to set a high data_offset to leave plenty of head
room it is much more important to leave enough space to allow
of the data of the array.
So after we check that sb->size is still available, only reduce the
'reserved', don't increase it.
This fixes a bug where --adding a spare fails because it does not have
enough space in it.
Reported-by: nowhere <nowhere@hakkenden.ath.cx>
Signed-off-by: NeilBrown <neilb@suse.de>
fbdef49811 incorrectly tried to fix sign
extension of the bitmap offset. However mdinfo->bitmap_offset is a u32
and needs to be converted to a 32 bit signed integer before the sign
extension.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The kernel is growing the ability to avoid the need for a
backup file during reshape by being able to change the data offset.
For this to be useful we need plenty of free space before the
data so the data offset can be reduced.
So for v1.1 and v1.2 metadata make the default data_offset much
larger. Aim for 128Meg, but keep a power of 2 and don't use more
than 0.1% of each device.
Don't change v1.0 as that is used when the data_offset is required to
be zero.
Signed-off-by: NeilBrown <neilb@suse.de>
As the bitmap can be before the superblock, bitmap_offset is signed.
But some of the code didn't honour that :-(
Signed-off-by: NeilBrown <neilb@suse.de>
RAID10 arrays with an odd number of devices had the arraysize
reported wrongly by --examine due to a rounding error.
Reported-by: Chris Francy <zoredache@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This uses a struct to cache the block size for aligned reads/writes,
to avoid repeated ioctl(BLKSSZGET) calls.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Avoid possibly using stale data in bitmap and misc area of superblock.
In addition, remove superfluous memsets already covered by memset of
full superblock.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Use a #define rather than calculate the size of the superblock buffer
on every allocation.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
We just calculated the pointer to the bitmap, so use it instead of
recalculating.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The current 1024 byte limit on 1.x superblocks limits us to
384 devices. Sometimes people want more.
The kernel is already prepared for superblocks up to 4K,
so enable that in mdadm allowing up to
(4096-256)/2 == 1920
devices (active plus spare).
Signed-off-by: NeilBrown <neilb@suse.de>
In addition remove attempt to print an error message if
write_init_super() fails, as this is handled in the various
write_init_super() functions. This avoids a segfault on error.
Reported by Jim Meyering in
https://bugzilla.redhat.com/show_bug.cgi?id=795461
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This makes super[01].c properly align buffers used for the bitmap
using posix_memalign() to make sure the writes don't fail in case the
bitmap is opened using O_DIRECT.
This is based on https://bugzilla.redhat.com/show_bug.cgi?id=789898
and an initial patch by Alexander Murashkin.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
A recently change to write_bitmap1 meant awrite would sometimes
write from a non-aligned buffer which of course break.
So change awrite (and aread) to always use their own aligned
buffer to ensure safety.
Reported-by: Alexander Lyakas <alex.bolshoy@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
when deciding whether the array is clean or dirty, compare
sb->resync_offset against MaxSector and not against sb->size
With RAID6 resyncing and subsequent drive failures, it is possible to
reach the case, in which sb->resync_offset==sb->size. This happens
when resync is aborted due to drive failures, and immediately a
rebuild of a spare starts. In this case, mdadm was considered the
array as clean, while kernel was considering the array as dirty. It is
better for mdadm also to consider the array as dirty in this case.
Signed-off-by: NeilBrown <neilb@suse.de>
Adding a bitmap via ioctl can only add it at a fixed location.
That location is not suitable for 4K-block devices.
So allow setting the bitmap location via sysfs if kernel supports it
and aim to always use 4K alignments.
Signed-off-by: NeilBrown <neilb@suse.de>
When container is assembled while reshape is active on one of its member
whole container can be required to be blocked from monitoring.
For such purpose field recovery blocked is added to mdinfo structure.
When metadata handler finds active reshape in container it should set
recovery_blocked field to disable whole container monitoring during
reshape.
For arrays that doesn't use containers, recovery_blocked field
has the same value as reshape_active field e.g. super0/1.
In fact,recovery is blocked during reshape for such arrays.
For ddf, metadata handler doesn't set reshape_active field,
so recovery_blocked is not set also.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If you create a two drive raid1 array with one device writemostly, then
fail the readwrite drive, when you add a new device, it will get the
writemostly bit copied out of the remaining device's superblock into
it's own. You can then remove the new drive and readd it as readwrite,
which will work for the readd, but it leaves the stale WriteMostly1 bit
in devflags resulting in the device going back to writemostly on the
next assembly.
The fix is to make sure that A) when we readd a device and we might have
filled the st->sb info from a running device instead of the device being
readded, then clear/set the WriteMostly1 bit in the super1 struct in
addition to setting the disk state (ditto for super0, but slightly
different mechanism) and B) when adding a clean device to an array (when
we most certainly did copy the superblock info from an existing device),
then clear any writemostly bits.
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Some code currently clears 'info' before calling getinfo_super,
some code doesn't.
To be consistent, change it so no caller ever clears 'info',
but ever getinfo_super function must clear it.
Note that ->raid_disk may be meaningful if that 'map' is passed
non-NULL. In that case it is copied out before the structure
is zeroed.
Signed-off-by: NeilBrown <neilb@suse.de>
As homehost defaults to the system name it is not possible to specify
a NULL homehost.
This patch restored this ability with either --homehost="" or
--homehost="<none>".
This allows the creation of v1.x arrays without a "hostname:"
prefix in the name.
Signed-off-by: NeilBrown <neilb@suse.de>
the new code for defaulting chunksizes didn't work quite right
- default was set to late in super1/super0/ddf
- defaults would over-ride values of '0' imposed by some levels
- default value wasn't applied to size properly.
Signed-off-by: NeilBrown <neilb@suse.de>
When chunk size is not set from command line we need to guess it
depending on metadata given on command line or found on listed devices.
Validate_geometry sets the default for it's metadata if chunk is not set.
For external metadata chunk is set only when creating in a container.
For imsm validate_geometry_imsm_orom is responsible for finding default
chunk depending on container metadata loaded. Container will already know
which controller it is attached to, and have this controllers orom
available.
do_default_chunk indicates that we need to find default chunk and
if validate_geometry fails for some metadata it tells us to reset chunk
that may have been set.
Current solution would set default chunk correctly for imsm only if
container device was given on command line. With the list of devices
chunk was always set to 512.
Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When we force-assemble an array which is in the middle of a reshape,
we should repeat the reshape of any parts that aren't recorded in
the oldest superblock.
This is unlikely to make a significant difference, but could make
a small difference, and is safer.
Signed-off-by: NeilBrown <neilb@suse.de>
Now that a 'supertype' container more information, the simplistic
copying of 'st' into 'refst' is incorrect and results in closing
some fds when load_super1(refst) calls free_super().
So do it more correctly using dup_super.
Reported-by: "Labun, Marcin" <Marcin.Labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
We previously closed all 'fds' associated with an array in
write_init_super .. sometimes, and sometimes at bad times.
This isn't neat and free_super is a better place to close them.
So make sure free_super always closes the fds that the metadata
manager kept hold of, and stop closing them in write_init_super.
Also add a few more calls to free_super to make sure they really do
get closed.
Reported-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
It makes more sense to test for container_dev than for subarray
for several places in Create where it then uses container_dev.
This allows us to subsequently remove subarray.
Signed-off-by: NeilBrown <neilb@suse.de>
This allows the info for a single array to be extracted,
so we don't have to write it into st->subarray.
For consistency, implement container_content for super0 and super1,
to just return the mdinfo for the single array.
Signed-off-by: NeilBrown <neilb@suse.de>
To accurately detect when an array has been split and is now being
recombined, we need to track which other devices each thinks is
working.
We should never include a device in an array if it thinks that the
primary device has failed.
This patch just allows get_info_super to return a list of devices
and whether they are thought to be working or not.
Signed-off-by: NeilBrown <neilb@suse.de>
If an --update is requested by the relevant metadata doesn't
understand it, print a useful message rather than silently ignoring
the issue.
Signed-off-by: NeilBrown <neilb@suse.de>
This code is wrong is several ways, and failed on big-endian machines.
Put in correct endian coversions: 'want' is cpu-order, dev_roles[] is little-endian,
16 bit.
Reported-by: Doug Nazar <nazard.michi@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This number isn't meaningful for RAID0 as a different amount of space
might be used from each device.
It isn't meaningful for linear either, but already was not reported
for linear.
Detail doesn't report it either.
So make --examine not report it.
Signed-off-by: NeilBrown <neilb@suse.de>
Reported-by: Mario 'BitKoenig' Holbe <Mario.Holbe@TU-Ilmenau.DE>
This commit introduces DEFAULT_OLD_METADATA as a preprocessor
definition. If defined, it causes mdadm to assume metadata version 0.9
as default. If not defined, version 1.x (currently 1.2) is used as
default.
The man page mdadm.8 is also modified to reflect the chosen default.
The selftests will not work if the old default is chosen.
This patch was requested by Debian so they could distribute a current
mdadm together with boot loaders that only understand 0.90 metadata
for md-raid.
Preferred usage is simply
make DEFAULT_OLD_METADATA=yes
Signed-off-by: martin f. krafft <madduck@debian.org>
Signed-off-by: NeilBrown <neilb@suse.de>
If the metadata is an empty string, it means the array in question
does not use metadata. This comes from sysfs_read finding "none" in
"metadata_version", then super_by_fd noticing the vers == -1, and so
just using the ->text_version (which is empty).
In this case we want to use the super0 metadata handler routines
because that is what we always used to do before
commit 7d5c3964cc
And that commit was wrong because "" doesn't mean "default" and so
should not have been changed at the same time.
Reported-by: martin f. krafft <madduck@debian.org>
Signed-off-by: NeilBrown <neilb@suse.de>
For 1.1 and 1.2 metadata where data_offset is not zero,
it is important to align the data_offset to underlying
block size.
We don't currently have access to the particular device
in avail_size so just try to force to a 1Meg boundary.
Also default 1.x metadata to 1.2 as documented.
Signed-off-by: NeilBrown <neilb@suse.de>
Change default - again, sorry.
v1.1 causes problems as the conflicts with a boot sector, whether on
the whole device or in a partition. I guess the rule is they you
aren't allowed to use the first sector in general.
v1.2 is mostly just as good and avoid boot-sector problems so default
to that instead.
Signed-off-by: NeilBrown <neilb@suse.de>
Some devices have 4K sector sizes. So try to align the bitmap
on a 4K boundary.
This isn't possible when hot-adding a bitmap, but will be once
we add support for configuring the bitmap via sysfs.
Signed-off-by: NeilBrown <neilb@suse.de>
1.x metadata allows a device to be a member of the array while it
is still recoverying. So it is a working member, but is not
completely in-sync.
mdadm/assemble does not understand this distinction and assumes that a
work member is fully in-sync for the purpose of determining if there
are enough in-sync devices for the array to be functional.
So collect the 'recovery_start' value from the metadata and use it in
assemble when determining how useful a given device is.
Reported-by: Mikael Abrahamsson <swmike@swm.pp.se>
Signed-off-by: NeilBrown <neilb@suse.de>
Replace occurrences of ~0ULL to make it clear we are talking about maximal
resync/recovery position.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
- When --kill-superblock is used with --metadata, find every
different superblock if there are several and kill them all.
- When creating a new array, kill off any old metadata. The code
to do this was already present but has become broken over time.
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>
A small bitmap-chunksize hurts performance without helping
resync speed much - particularly on internal bitmaps.
So set the default to at least 64Meg.
Signed-off-by: NeilBrown <neilb@suse.de>
1.1 is more flexible in a number of ways and is safer.
0.90 is still fully supported.
1.0 should possibly be used for RAID1 arrays that you
want to boot off, depending on your boot loader.
Signed-off-by: NeilBrown <neilb@suse.de>
Previously such things did not exist: ACTIVE and SYNC were either both
set or both clear. Recent changes with reshape means that a device
can be ACTIVE but not yet fully in-sync, so they need to be handled
and included in the array as active devices.
Signed-off-by: NeilBrown <neilb@suse.de>
Because ---examine --brief, or --detail --brief are
often used to create mdadm.conf, and because people don't want to
have to update their mdadm.conf unnecessarily, we don't want to
include information that might change.
And now that level changing is supported, that is almost everything
but UUID.
So move some more fields into the "Only print with --verbose" class.
Signed-off-by: NeilBrown <neilb@suse.de>
The line 'auto' in mdadm.conf can be used to disable assembly
of specific metadata types, or of all arrays.
This does not affect assembly of arrays listed in mdadm.conf
or on command line.
auto -all
will disable all auto-assembly.
auto -ddf
will cause mdadm to ignore ddf arrays that are not explicitly
mentioned, and auto assemble anything else it finds.
Signed-off-by: NeilBrown <neilb@suse.de>
Apparently the dereferencing of a type-punned pointer breaks strict
aliasing rules. And we wouldn't want to do that.
So just make a different array of the appropriate type and use memcpy.
Resolves-Debian-bug: 505375
Signed-off-by: NeilBrown <neilb@suse.de>
The information about how slots and roles in the array lined up
turned out to be confusing.
So simplify it and one provide the interesting information.
Signed-off-by: NeilBrown <neilb@suse.de>
If the sector size is > 512, we need to be more careful about
alignment.
The largest known sector size is 4096 and (fortunately) both the
superblock and (in many cases) the bitmap are 4096-byte aligned.
So there should be no data-overlap problems.
The exception is when the bitmap is squeezed into the 3K after the
superblock. This arrangement cannot currently be supported on
4K sector-size devices.
Signed-off-by: NeilBrown <neilb@suse.de>
There was a few kernel releases where the kernel would shrink max_dev
to be just enough to hold the current number of devices.
More recent kernels never shrink it.
However to be as compatible as possible, if we notice that
max_dev is too small to successfully add a device, increase it.
Signed-off-by: NeilBrown <neilb@suse.de>
Metadata formats like imsm work in concert with platform firmware and
hardware, so provide a way for mdadm to display this info to the user.
Signed-off-by: Dan Williams <dan.j.williams@intel.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>
Signed-off-by: NeilBrown <neilb@suse.de>
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>
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
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.
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].
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.
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.
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>
NeilBrown
Maciej Naruszewicz
majianpeng
Jes Sorensen
Alexander Lyakas
Adam Kwolek
Doug Ledford
Scott Schaefer
Luca Berra
Czarnowska, Anna
martin f. krafft
Dan Williams
Kay Sievers
Jérémy Bobbio
Kay Sievers