summaryrefslogtreecommitdiff
path: root/Incremental.c
Commit message (Collapse)AuthorAge
* Assemble/Incremental: don't hold O_EXCL on mddev after assembly.NeilBrown2013-12-05
| | | | | | | As soon as the array is assembled, udev or systemd might run fsck and mount it. So we need to drop O_EXCL promptly. Signed-off-by: NeilBrown <neilb@suse.de>
* Incremental: improve support for "DEVICE" based restriction in mdadm.confNeilBrown2013-12-03
| | | | | | | | | | | | | | | | | --incremental currently fails if the device name passed does not textually match the names permitted by the DEVICE line in mdadm.conf. This is problematic when "mdadm -I" is run by udev as the name given can be a temp name. This patch makes two improvements: 1/ We generate a list of all existing devices that match the names in mdadm.conf, and allow rdev based matching 2/ We allows extra aliases to be provided on the command line, and perform textual matching on those. This is particularly suitable for udev usages as ${DEVLINKS} can be provided even though the links make not yet be created. Signed-off-by: NeilBrown <neilb@suse.de>
* Incremental: add --export handling.NeilBrown2013-11-28
| | | | | | | | | | | | | | | | | | | | | | | | | | If --export is given with --incremental, then MD_DEVNAME is output which gives the name of the device (in /dev/md) that is the array (or container) that the device would be added to. Also MD_STARTED is set to one of no unsafe yes nothing to indicate if the array was started. IF MD_STARTED=unsafe then it may be appropriate to run mdadm -R /dev/md/$MD_DEVNAME after a timeout to ensure newly degraded array are started. If MD_FOREIGN=yes it might be appropriate to suppress this as the array is probably not critical. Signed-off-by: NeilBrown <neilb@suse.de>
* Incremental: don't abort container if one member explicitly disabled.NeilBrown2013-11-28
| | | | | | | If a member of a container is explicitly disabled, others may not be so we should continue. Signed-off-by: NeilBrown <neilb@suse.de>
* Incremental: remove test that can never succeed.NeilBrown2013-11-28
| | | | | | | | Incremental_container never returns 1, so this test is pointless. It is a holdover from when we called "Incremental()" rather than "Incremental_container()" at this point. Signed-off-by: NeilBrown <neilb@suse.de>
* Make -IRs and --run work properly for containers.NeilBrown2013-09-13
| | | | | | | | We really need to make sure assemble_container_content() gets called to finished the assembly of these. Reported-by: Francis Moreau <francis.moro@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Release mdadm-3.3NeilBrown2013-09-03
| | | | | | (and various cosmetic fixes) Signed-off-by: NeilBrown <neilb@suse.de>
* Change "mdadm --run" to use the same code as "mdadm --IRs".NeilBrown2013-08-26
| | | | | | | | | | | Current "mdadm --run /dev/mdX" will not handle external metadata properly. mdmon won't be started etc. So use the code from "mdadm -IRs" instead - that already does all the right things. Reported-by: Francis Moreau <francis.moro@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Manage: split Manage_runstop into Manage_run and Manage_stopNeilBrown2013-06-19
| | | | | | | The two branches have virtually nothing in common, so it is simpler if they are separate. Signed-off-by: NeilBrown <neilb@suse.de>
* Assemble/Incr: Don't include spares with too-high event count.NeilBrown2013-06-17
| | | | | | | | | | | Some failure scenarios can leave a spare with a higher event count than an in-sync device. Assembling an array like this will confuse the kernel. So detect spares with event counts higher than the best non-spare event count and exclude them from the array. Reported-by: Alexander Lyakas <alex.bolshoy@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Incremental: allow --quiet to silence from errors from "-If"NeilBrown2013-05-29
| | | | | | | -q is currently ineffective on "mdadm -If". Messages that are not usage errors should be suppressed. Signed-off-by: NeilBrown <neilb@suse.de>
* Change some "fprintf(stderr,"s to pr_err.NeilBrown2013-05-21
| | | | | | They just keep slipping in.. Signed-off-by: NeilBrown <neilb@suse.de>
* Incremental: remove partitions when assembling.NeilBrown2013-05-14
| | | | | | | | We remove partitions for --create and --assemble, but not for --incrmental. So fix that ommision. Signed-off-by: NeilBrown <neilb@suse.de>
* Incrmental: tell udevs to unmount when array looks to have disappeared.NeilBrown2013-05-13
| | | | | | | | | | If a device is removed which appears to be busy in an md array, then it is very like the array cannot be used. We currently try to stop it, but that could fail if udisks had automatically mounted it. So tell udisks to unmount it, but ignore any error. Signed-off-by: NeilBrown <neilb@suse.de>
* Enhance incremental removal.NeilBrown2013-03-05
| | | | | | | | | | | | | | | | | | | | | | | | | When asked to incrementally-remove a device, try marking the array read-auto first. That will delay recording the failure in the metadata until it is really relevant. This way, if the device are just unplugged when the array is not really in use, the metadata will remain clean. If marking the default as faulty fails because it is EBUSY, that implies that the array would be failed without the device. As the device has (presumably gone) - that means the array is dead. So try to stop it. If that fails because it is in use, send a uevent to report that it is gone. Hopefully whoever mounted it will now let go. This means that if you plug in some devices and they are auto-assembled, then unplugging them will auto-deassemble relatively cleanly. To be complete, we really need the kernel to disassemble the array after the last close somehow. Maybe if a REMOVE has failed and a STOP has failed and nothing else much has happened, it could safely stop the array on last close. Signed-off-by: NeilBrown <neilb@suse.de>
* Discard devnum in favour of devnmNeilBrown2013-02-21
| | | | | | | | | | | | | | 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>
* Incremental: allow recently removed device to be added as a spare.NeilBrown2012-11-20
| | | | | | | | | | | | | Currently, action=force-spare isn't effective at all as I'm not sure what is really sensible. This patch allows a device that was part of an array, but has been removed, to be added as a spare of passed to --incremental while force-spare is active. If it is can be re-added, that done first. If it fails, we add it as a spare. Signed-off-by: NeilBrown <neilb@suse.de>
* IMSM - allow assembling any imsm array even without OROM.NeilBrown2012-11-20
| | | | | | | | | | | | | | | | It is important to check for compatibility with 'platform' or Option ROM when creating or changing and array. However there is no real need when simply assembling the array. On some systems there are situations where the platform information is not available. e.g. on some UEFI systems, UEFI is not available during 'kdump' handling. This makes it impossible to assemble an IMSM array to receive the dump. So remove the requirements that the platform be visible to assemble an IMSM array. Signed-off-by: NeilBrown <neilb@suse.de>
* Incremental: support replacement devices.NeilBrown2012-10-24
| | | | | | These need to be counted in the number of 'active' devices. Signed-off-by: NeilBrown <neilb@suse.de>
* Fix up interactions between --assemble and --incrementalNeilBrown2012-10-10
| | | | | | | | | | | | | | If --incremental has partly assembled an array and --assemble is asked to assemble it, the just finds remaining devices and makes a new array. Not good. So: 1/ modify locking policy so that assemble can be sure that no --incremental is running once it locks the map file 2/ Assemble() checks the map file for a duplicate and adds to that array instead of creating a new one. Signed-off-by: NeilBrown <neilb@suse.de>
* New RESHAPE_NO_BACKUP flag to track when backup action is needed.NeilBrown2012-10-04
| | | | | | | | | | | | 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>
* Add data_offset arg to ->avail_sizeNeilBrown2012-10-04
| | | | | | | 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>
* Minor cosmetic fixes in various files.NeilBrown2012-08-13
| | | | Signed-off-by: NeilBrown <neilb@suse.de>
* Change Incremental and related functions to take struct contextNeilBrown2012-07-09
| | | | Signed-off-by: NeilBrown <neilb@suse.de>
* Assemble: allow arrays to be assembled read-only.NeilBrown2012-07-09
| | | | | | The option was there, but never used. Signed-off-by: NeilBrown <neilb@suse.de>
* Remove scattered checks for malloc success.NeilBrown2012-07-09
| | | | | | | | | | | | | | 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>
* Remove re_add flag in favour of new disposition.NeilBrown2012-07-09
| | | | | | | | | | | Instead of disposition == 'a' re_add == 1 use disposition == 'A' to record that a re-add was requested. Signed-off-by: NeilBrown <neilb@suse.de>
* Introduce pr_err for printing error messages.NeilBrown2012-07-09
| | | | | | | 'pr_err("' is a lot shorter than 'fprintf(stderr, Name ": ' cont_err() is also available. Signed-off-by: NeilBrown <neilb@suse.de>
* Incremental: fix adding devices with --incrementalNeilBrown2012-03-22
| | | | | | | | | | | | We should use 'info' here, not 'info2'. info2 refers to some other device (There may not even be one).l info is *this* disk. This is particularly important for getting info.disk.state correct, which the kernel depends on to get 're-add' functionality correct. Signed-off-by: NeilBrown <neilb@suse.de>
* avoid double-free upon "old buggy kernel" sysfs_read failureJim Meyering2012-02-22
| | | | | | | | | * Incremental.c (Incremental): On sysfs_read failure, don't call sysfs_free(sra) just before "goto out_unlock", since that very same "sra" is freed the same way by the clean-up code below. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Remove avail_disks arg from 'enough'.NeilBrown2012-02-07
| | | | | | | | It can easily be calculated from 'avail' and 'raid_disks', and we will soon have a case where we don't have it easily available to pass in. Signed-off-by: NeilBrown <neilb@suse.de>
* fix: container creation with --incremental used.Lukasz Dorau2012-01-12
| | | | | | | | | | | If there is no name provided for a container by the metadata it is always appropriate to use the metadata version name. create_mddev will still add a uniquifying digit to the end so there is little risk of confusion. This makes the --incremental code behave the same as the --assemble code. Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Assemble: make some plurals conditional.NeilBrown2011-12-23
| | | | | | "1 devices" is ugly. Fix it. Signed-off-by: NeilBrown <neilb@suse.de>
* Incremental: make sure container name appears in /devNeilBrown2011-12-23
| | | | | | | | | | | | | | | | | We need to send a "change" event just like we do when creating an array. This reverts commit 382afe49b10cf3e5a4764cee74649d1cd8c91813 The problem is that we need udev to create the file in /dev for us. It might be unnecessary for udev to consider assembling things in this array, but it shouldn't cause a problem. If it did that would be a different bug which we probably need locking to fix. Or maybe udev shouldn't trigger a "-I" for containers appearing. Signed-off-by: NeilBrown <neilb@suse.de>
* array_try_spare(): open_dev() returns -1 on error, not zeroJes Sorensen2011-11-03
| | | | | Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
* IncrementalScan(): Fix memory leakJes Sorensen2011-11-02
| | | | | Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Incremental(): Check return value of dev_open() before trying to use itJes Sorensen2011-11-02
| | | | | Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Incremental: Fix a merge error in recent patchNeilBrown2011-11-01
| | | | | | | | | commit 81219e70f2a9be7292046860ea15528fe5854cab required merging and I messed it up. The locking shouldn't be there - the caller locks now. Reported-by: "Labun, Marcin" <Marcin.Labun@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
* partition_try_spare() use closedir() to release DIR * returned by opendir()Jes Sorensen2011-11-01
| | | | | Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Fix memory leak of 'st3' in array_try_spare()Jes Sorensen2011-11-01
| | | | | Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Remove duplicated code: search_mdstat and conf_matchNeilBrown2011-11-01
| | | | | | | | | search_mdstat and conf_match are almost identical. Put all the functionality in conf_match, and remove search_mdstat. Reported-by: Jes.Sorensen@redhat.com Signed-off-by: NeilBrown <neilb@suse.de>
* kill-subarray: fix, IMSM cannot kill-subarray with unsupported metadataLabun, Marcin2011-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | container_content retrieves volume information from disks in the container. For unsupported volumes the function was not returning mdinfo. When all volumes were unsupported the function was returning NULL pointer to block actions on the volumes. Therefore, such volumes were not activated in Incremental and Assembly. As side effect they also could not be deleted using kill-subarray since "kill" function requires to obtain a valid mdinfo from container_content. This patch fixes the kill-subarray problem by allowing to obtain mdinfo of all volumes types including unsupported and introducing new array.status flags. There are following changes: 1. Added MD_SB_BLOCK_VOLUME for blocking an array, other arrays in the container can be activated. 2. Added MD_SB_BLOCK_CONTAINER_RESHAPE block container wide reshapes (like changing disk numbers in arrays). 3. IMSM container_content handler is to load mdinfo for all volumes and set both blocking flags in array.state field in mdinfo of unsupported volumes. In case of some errors, all volumes can be affected. Only blocked array is not activated (also reshaped as result). The container wide reshapes are also blocked since by metadata definition they require modifications of both arrays. 4. Incremental_container and Assemble functions check array.state and do not activate volumes with blocking bits set. 5. assemble_container_content is changed to check container wide reshapes before activating reshapes of assembled containers. 6. Grow_reshape and Grow_continue_command checks blocking bits before starting reshapes or continueing (-G --continue) reshapes. 7. kill-subarray ignores array.state info and can remove requested array. Signed-off-by: Marcin Labun <marcin.labun@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Incremental() lock error handlingJes Sorensen2011-10-22
| | | | | Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
* array_try_spare(): missing map_unlock()Jes Sorensen2011-10-22
| | | | | Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Don't tell sysfs to launch the container as we are doing it ourselvesJes Sorensen2011-10-22
| | | | | Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Remove race for starting container devices.Jes Sorensen2011-10-22
| | | | | | | | | | | | | | This moves the lock handling out of Incremental_container() and relies on the caller holding the lock. This prevents conflict with a follow-on mdadm comment which may try and launch the device in parallel. This involves replacing a call to "Incremental" with an unrolled version with just the case that calls Incremental_container and so needs a call to ->load_container. Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Do not continue reshape during initrd phaseAdam Kwolek2011-10-03
| | | | | | | | | | | | | | During initrd phase continuing reshape will cause file system context lost. This blocks ability to control reshape using checkpoints. To avoid this, during initrd phase assemble has to be executed with '--freeze-reshape' option. This causes that mdadm restores reshape critical section only. Reshape can be continued later after system full boot. Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
* fix: correct unlocking of map fileLukasz Dorau2011-10-03
| | | | | | | | 1. Three missing map_unlock() calls were added. 2. Map file must be unlocked on fork, else child will hold lock. Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Discourage large devices from being added to 0.90 arrays.NeilBrown2011-09-08
| | | | | | | | 0.90 arrays can only use up to 4TB per device. So when a larger device is added, complain a bit. Still allow it if --force is given as there could be a valid use. Signed-off-by: NeilBrown <neilb@suse.de>
* FIX: Prevent using null list pointerNeilBrown2011-09-07
| | | | | | | | | When not all attributes are supported (attributes incompatibility) function container_content_imsm returns NULL pointer. We need to cope with a NULL list better. Reported-by: Lukasz Dorau <lukasz.dorau@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-30 12:40:43 +0000