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>
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.
In 2.6.17 (and prior), the dev_number is ignored when a device
is added to an active array. Rather the first free number is used.
So we work around this by making sure we use the first free
number for dev_number.
Description...
While declaring variables in the middle of code withs with
newer gcc's it doesn't work with older, and it is arguably
less readable, so just do the right thing.
From: Paul Clements <paul.clements@steeleye.com>
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>
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
NOTE: This is an incompatable change affecting raid5 reshape.
If you want to reshape a raid5 using version-1 superblocks,
use 2.6.17-rc2 or later, and mdadm-2.4.1 or later.
Signed-off-by: Neil Brown <neilb@suse.de>
- report Intent Bitmap in --detail
- report internal bitmap in --examine
- pass' --force through to --grow --bitmap
- support v.large arrays in --grow --bitmap
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>
NeilBrown
Czarnowska, Anna
martin f. krafft
Dan Williams
Doug Ledford
Kay Sievers
Jérémy Bobbio
Kay Sievers
Paul Clements