GNOME Bugzilla – Bug 709640
Linux Swap Suspend and Software RAID partitions not recognised
Last modified: 2013-12-09 18:11:08 UTC
I've been using Linux Software RAID recently and seen than GParted doesn't recognise partitions containing RAID members, dispite it showing partitions within RAID arrays. GParted also doesn't recognise partitions containing Swap Suspend data.
Created attachment 256732 [details] [review] Suspend and Linux RAID recognition (draft 1) Hi Curtis, Here's the first draft of the patch set. I only wan't to do a minimal support. That is recognition only and for RAID, detection of busy status. A few questions: Q1) Is USE_LIBPARTED_DMRAID only about use of dmraid (aka BIOS / Fake RAID devices) and (and whether to use libparted implementation or not)? It is therefore completely independant to Linux Software RAID? It appears to be the case as far as I can tell. Q2) During startup and when doing Device Refresh non-active Software RAID arrays are being automatically started. Do you have any pointers as to what would be doing this? This is true for GParted even before this patch set. Thanks, Mike
Hi Mike, The combination of swap, suspension, device mapper RAID (dmraid) and Linux software RAID can get quite complex, as you likely already know. For example, multiple raw devices can be combined to form a RAID that is partitioned (or not). Alternately, each raw device can be first partitioned, and then those partitions placed into RAID formations, and those RAID formations can then be optionally partitioned. My own personal RAID experience is not extensive, but I do have a BIOS / FAKE RAID set up on my development computer. I have also set up a Linux software RAID on my MythTV PVR. I had noticed problems with file system/swap recognition within the Linux software RAID partitions. Further muddying the waters is that some BIOS / FAKE RAID implementations are recognized by both device mapper RAID and Linux software RAID. Regarding Linux swap / suspended partitions not being recognized we have two existing open bug reports: Bug #334569 - Swap partition is detected as "unknown", when a hibernation signature is on it Bug #692051 - Swap is shown as unknown The latter one involves LUKS encryption, which is yet another layer of complexity. The flexibility of block devices can make for some very sophisticated configurations. Now onto your questions. :-) A1) Your assumption about --use-libparted-dmraid is exactly as you surmised. More specifically: If enabled, GParted will only use the DMRaid method to detect device mapper RAID partitions. All other partition device path creation is left up to the libparted library. Note that not all versions of the libparted library support dmraid. If disabled, GParted will use the DMRaid method to not only detect device mapper RAID partitions, but also to create and remove the dmraid device path entries. One of the challenges in this area comes about from inconsistent partition name schemes. The most commonly used Linux partition naming scheme is to append "p" and the partition number after the device name _IF_ the device path ends in a number. If the device path ends in a letter, then append only the partition number. For example: Device: /dev/mapper/isw_efjbbijhh_Vol0 Partition: /dev/mapper/isw_efjbbijhh_Vol0p1 <-- Note 'p1' Device: /dev/mapper/isw_efjbbijhh_Volume Partition: /dev/mapper/isw_efjbbijhh_Volume1 Early versions (perhaps all?) of device mapper RAID would only append the partition number. For example: Device: /dev/mapper/isw_efjbbijhh_Vol0 Partition: /dev/mapper/isw_efjbbijhh_Vol01 <-- Note discrepancy Device: /dev/mapper/isw_efjbbijhh_Volume Partition: /dev/mapper/isw_efjbbijhh_Volume1 The GParted DMRaid code tries to work around these discrepancies and to ensure that the partition device paths are created or deleted as required. Further complicating this is that sometimes the control of the real device path is handled under /dev instead of /dev/mapper. For example: /dev/mapper/isw_efjbbijhh_Vol0 -> ../dm-0 /dev/mapper/isw_efjbbijhh_Vol0p1 -> ../dm-1 A2) Response to auto start up of Software RAID arrays. At start up, and at device refresh, GParted calls the libparted function ped_disk_commit_to_os() to test if the partition table has write access. We use ped_disk_commit_to_os() to determine if we should mark a device as read-only and hence restrict partition editing actions. See: https://git.gnome.org/browse/gparted/tree/src/GParted_Core.cc#n310 The libparted function ped_disk_commit_to_os() removes and re-adds the partition entries. This can cause automount programs to see a new device and mount it. Perhaps something similar is happening with Linux software RAID? I noticed that you labelled your patch as "draft 1". Is there something specific you would like me to test with this patch? Or should I wait for an upcoming patch? Curtis
Hi Curtis, I only combined recognition of suspend and software RAID as a single patch because they both change the same files in the same ways. I can easily split it into separate patches if you wish. Looking at bug #334569 software-suspend2 was being used for hibernation. As far as I can tell that is defunct. The current implementation included in the kernel is Linux Software Suspend and uses a different on disk signature, but both libparted and blkid recognise that signature. $ blkid /dev/sda10 /dev/sda10: ... TYPE="swsuspend" $ parted /dev/sda print ... Number Start End Size Type File system Flags ... 10 361GB 362GB 1074MB logical swsusp I labelled my patch as draft 1, mostly because I hadn't done anything about (Q2) GParted refresh causing auto start of Software RAID arrays, and to see if that would be OK to leave. I will have a look to see if I can work out what is triggering the arrays to auto start. Also is the reset of scope of the patchset OK? GParted isn't ready for RAID management, and I don't even want to add activating or stopping arrays. I just want it to recognise array members, and their busy status. Is this OK and worth having? Thanks, Mike
Hi Mike, (In reply to comment #3) > I only combined recognition of suspend and software RAID as a single > patch because they both change the same files in the same ways. I can > easily split it into separate patches if you wish. No need to split the patches on my account. :-) > Looking at bug #334569 software-suspend2 was being used for hibernation. > As far as I can tell that is defunct. The current implementation > included in the kernel is Linux Software Suspend and uses a different on > disk signature, but both libparted and blkid recognise that signature. > > $ blkid /dev/sda10 > /dev/sda10: ... TYPE="swsuspend" > > $ parted /dev/sda print > ... > Number Start End Size Type File system Flags > ... > 10 361GB 362GB 1074MB logical swsusp Thanks for this info. I will add these details to the other report and close it. > Also is the rest of scope of the patchset OK? GParted isn't ready for > RAID management, and I don't even want to add activating or stopping > arrays. I just want it to recognise array members, and their busy > status. Is this OK and worth having? I will test the patch later, or an updated one if you make more progress on this before I get a chance to test. ;-) I agree that the base functionality you added with this patch is worth while. Curtis
Hi Curtis, I've been testing the issue with stopped arrays being automatically started by Refresh Devices in GParted and worked out what is happening. As you suspected it starts with commit_to_os() and goes like this: * GParted commit_to_os() * libparted ped_disk_commit_to_os() * libparted does ioctl() BLKPG_DEL_PARTITION * kernel emits udev partition remove event * liparted does ioctl() BLKPG_ADD_PARTITION * kernel emits udev partition add event * udev rule file 65-md-incremental.rules contains this rule which incrementally starts this member in a Linux Software RAID array SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_TYPE}=="linux_raid_member", \ RUN+="/sbin/mdadm -I $tempnode" Just need to decide if we should try to prevent this and how. Mike
Hi Curtis, Just an update to the question of whether to prevent automatic starting of Linux Software RAID arrays. After some research I think that it will be relatively simple to prevent udev from automatically starting Linux Software RAID arrays. I will write an additional patch which adds some code to the gparted shell wrapper to determine if there is a udev rule which runs "mdadm -I" (incremental start) and add a runtime block. Mike
Created attachment 257165 [details] [review] Suspend and Linux RAID recognition (v1) Hi Curtis, Here's the patchset. Stopping udev automatically starting stopped Linux Software RAID arrays took a bit to work out to deal with the differences of udev over its life and more to test. I think the most important question was to name the new file systems. They are OK but I am open to change. GParted display linux-suspend linux-raid GParted internal FS_LINUX_SWSUSPEND FS_LINUX_SWRAID blkid output swsuspend linux_raid_member parted output swsusp (None) Could perhaps drop the linux / LINUX from the swap suspend display name and internal identifier. I included it because the related type is called linux-swap. Googling for "linux suspend" produced lots of meaningful hits so it's not a bad choice. Testing results: CentOS 5.9: - Has blkid from e2fsprogs-1.39. Recognises swsuspend. Doesn't recognise linux_raid_member. - Has libparted 1.8.1. Doesn't recognise swsusp. - Has udev 095 with only /etc/udev/rules.d directory and no rules files containing mdadm to incrementally start arrays. - Trying to manually incrementally start an array reports this: mdadm -I /dev/sdb1 mdadm: You have an old buggy kernel which cannot support --incremental reliably. Aborting. - Has kernel 2.6.18-348.16.1.el5. - GParted shell script wrapper correctly skips creating any blank override rules files. - GParted recognises linux-suspend. It can't recognise linux-raid. It doesn't automatically start stopped Linux Software RAID arrays. Doesn't report when linux-raid members are busy or not because it doesn't recognise linux-raid-members. - PASS Debian 6: - Has blkid from util-linux(-ng) 2.17.2. Recognises swsuspend and linux_raid_member. - Has libparted 2.3. Recognises swsusp. - Has udev 164 with /lib/udev/rules.d, /dev/.udev/rules.d and /etc/udev/rules.d directories. "mdadm --incremental" rule in /lib/udev/rules.d/64-md-raid.rules, but commented out. - GParted shell script wrapper correctly skips creating any blank override rules files because the mdadm command is commented out. - GParted refresh doesn't auto start array members. Recognises linux-suspend and linux-raid. Recognised busy linux-raid-members. - PASS CentOS 6.4: - Has blkid from util-linux(-ng) 2.17.2. Recognises swsuspend and linux_raid_member. - Has libparted 2.1. Recognises swsusp. This version of libparted doesn't use ioctl() BLKPG_{DEL,ADD}_PARTITION so doesn't generate the udev events to trigger array member incremental start. - Has udev 147 with /lib/udev/rules.d/, /dev/.udev/rules.d and /etc/udev/rules.d directories. "mdadm -I" rule commented out in 64-md-raid.rules and active in 65-md-incremental.rules. - Has kernel 2.6.32-358.18.1.el6.i686. - GParted shell script wrapper creates blank override rules file /dev/.udev/rules.d/65-md-incremental.rules. - GPrated recognises linux-suspend and linux-rand. Detects busy status of linux-raid-members. Recognises busy linux-raid-members. - PASS Fedora 18: - Has blkid from util-linux 2.22.2. Recognises swsuspend and linux_raid_member. - Has libparted 3.1. Recognises swsusp. - Has udev from systemd 201 with /lib/udev/rules.d and /etc/udev/rules.d directories. /run/udev exists, but /run/udev/rules.d doesn't. Strings of systemd-udevd shows /run/udev/rules.d. "mdadm -I" rule commented out in 64-md-raid.rules and active in 65-md-incremental.rules. - Has kernel 3.9.6-200.fc18.i686.PAE. - Gparted shell script wrapper creates /run/udev/rules.d and blank override rule files /run/udev/rules.d/65-md-incremental.rules. - GParted recognised linux-suspend and linux-raid. Refresh doesn't auto restart array members. - PASS Kubuntu 12.04 LTS: - Has blkid from util-linux 2.20.1. Recognises swsuspend and linux_raid_member. - Has libparted 2.3. Recognises swsusp. - Has udev 175 with /lib/udev/rules.d, /run/udev/rules.d and /etc/udev/rules.d. "mdadm -I" rule in 64-md-raid.rules. - Has kernel 3.2.0-40-generic-pae. - GParted shell script wrapper correctly creates temp blank rules file /run/udev/rules.d/64-md-raid.rules. - GParted detects busy linux-raid. Recognises linux-suspend and linux-raid. Refresh doesn't auto restart array members. - PASS Fedora 19 - Has blkid from util-linux 2.23.2. Recognises swsuspend and linux_raid_member. - Has libparted 3.1. Recognises swsusp. - Has udev from systemd 204 with /lib/udev/rules.d and /etc/udev/rules.d directories. No /run/udev/rules.d directory but /run/udev exists. Strings of systemd-udevd contains /run/udev/rules.d. "mdadm -I" rule is commented in 64-md-raid.rules and active it 65-md-incremental.rules. - Has kernel 3.11.3-201.fc19.i686.PAE. - GParted shell script wrapper created /run/udev/rules.d directory and empty override rule file 65-md-incremental.rule. - GParted recognises linux-suspend and linux-raid. Detects busy linux-raid. Refresh doesn't auto start array members. - PASS Thanks, Mike
Hi Mike, It looks like you've done quite extensive testing in the patch set from comment #7. Do you have some tips on how to test the patch set? Did you compile and test the code directly in each virtual machine? If running directly in a VM, how did you test the linux-suspend stuff? I generally don't suspend my Linux sessions, so my thoughts are that if I hiberate rather than shutdown Linux, then I would need to use a separate Live CD to boot up and test the "linux-suspend" state. Thanks, Curtis
Hi Curtis, I did compile and run on all those OSs, most of them happen to be VMs. I created a Software RAID array on all those OSs. Create a 2 partition mirror: mdadm --create /dev/md1 --level=raid1 --raid-devices=2 /dev/sdb1 /dev/sdb2 Check running status: cat /proc/mdstat Stop: mdadm --stop /dev/md1 Assemble (restart): mdadm --assemble /dev/md1 /dev/sdb1 /dev/sdb2 Describe array: mdadm -D /dev/md1 Examine member devices: mdadm -E /dev/sdb1 Stop: mdadm --stop /dev/md1 Erase: mdadm --zero-superblock /dev/sdb1 /dev/sdb2 For swap suspend I took some short cuts. I only suspended my netbook and copied the swap suspend partition off it using a rescue Linux and copied it to a partition on each of my OSs I tested. Both blkid and parted recognised the partition, or not, on each OS as per expectation based on the version of the tool as documented in the first patch and noted in testing recorded in comment #7. Looked at the blkid source and the following is enough for it to recognise a swap suspend partition: # echo S1SUSPEND | dd of=/dev/sda12 bs=1 seek=4086 # blkid /dev/sda12 /dev/sda12: TYPE="swsuspend" (lib)parted is more picky so won't recognise this. Thanks, Mike
I've just spotted a small mistake in the second patch, in Utils::swraid_member_is_active(). In the return true case it doesn't call input.close(). I suspect that when std::ifstream class's destructor is called it will get closed so won't leek open file handles; but it's still a logic error which needs fixing. You can still test if you wan't as fixing this won't change GParted behaviour anywhere. I'll fix over the weekend.
Created attachment 257688 [details] [review] Suspend and Linux RAID recognition (v2) Hi Curtis, Here's version 2 of the patchset. The only difference to version 1 is the correction to Utils::swraid_member_is_active() in the second patch. Thanks, Mike
Hi Mike, Thank you for the tips on testing, and for the updated patch. My testing has gone well. I made one minor change to commit 2/4 of the set, entitled: Detect busy status of Linux Software RAID members (#709640) In method Win_GParted::set_valid_operations() I added to the comment ", activate/deactivate ". CHANGE FROM: //Only permit mount/unmount, swapon/swapoff if action is available TO: //Only permit mount/unmount, swapon/swapoff, activate/deactivate if action is available Previously the comment contained "..." which was meant to indicate that other dual set actions were available. Currently there are only three, so added the extra [de]activate set. Following are my test results: Ubuntu 10.04 LTS: - Has blkid from util-linux(-ng) 2.17.2-0ubuntu1.10.04.2. Recognises swsuspend and linux_raid_member. - Has libparted 2.2-5ubuntu5.2. Recognises swsusp. - Has udev 151-12.3 with /lib/udev/rules.d, /dev/.udev/rules.d and /etc/udev/rules.d directories. "mdadm --incremental" rule in /lib/udev/rules.d/85-mdadm.rules is _not_ commented out. - GParted shell script wrapper creates blank override rules file in /dev/.udev/rules.d. Specifically, 85-mdadm.rules zero byte file. - GParted refresh does not auto start inactive array members. Recognises linux-suspend and linux-raid. Recognised busy linux-raid-members. - PASS Ubuntu 13.04 - Has blkid from util-linux 2.20.1-5.1ubuntu8. Recognises swsuspend and linux_raid_member. - Has libparted 2.3-11ubuntu1. Recognises swsusp. - Has udev 175-0ubuntu26 with /lib/udev/rules.d, /etc/udev/rules.d /run/udev/rules.d, and /dev/.udev/rules.d directories. "mdadm --incremental" rule is active in 64-md-raid.rules. - GParted shell script wrapper creates blank override rules file in /dev/.udev/rules.d. Specifically, 64-md-raid.rules zero byte file. - GParted refresh does not auto start inactive array members. Recognises linux-suspend and linux-raid. Recognised busy linux-raid-members. - PASS openSUSE 12.2 - Has blkid from util-linux 2.21.2-4.5.1. Recognises swsuspend and linux_raid_member. - Has libparted 2.4-24.2.2. Recognises swsusp. - Has udev 182-4.14.1 with /lib/udev/rules.d, /etc/udev/rules.d directories. Does not have /run/udev/rules.d, or /dev/.udev/rules.d directories. "mdadm --incremental" rule is active in 64-md-raid.rules. - GParted shell script wrapper created /run/udev/rules.d directory and empty override rules file 64-md-raid.rules. - GParted refresh does not auto start inactive array members. Recognises linux-suspend and linux-raid. Recognised busy linux-raid-members. - PASS The patch set from comment #11 has been committed to the gnome repository for inclusion in the next release of GParted. The relevant git commits can be viewed at the following links: Recognise Linux Swap Suspend and Software RAID partitions (#709640) https://git.gnome.org/browse/gparted/commit/?id=fac3f5b86556391a880271371642ac7df68718f6 Detect busy status of Linux Software RAID members (#709640) https://git.gnome.org/browse/gparted/commit/?id=d2e1130ad22eb3f52db4dc7f645ed4d5bf119d24 Prevent GParted starting stopped Linux Software RAID arrays (#709640) https://git.gnome.org/browse/gparted/commit/?id=a255abf3432ad106fac9c766f0816ada20be8e42 Remove unused function declarations for *_mtoolsrc_file() https://git.gnome.org/browse/gparted/commit/?id=7ae05b7241d9067174ad291874225d033a4c1dee
I just noticed this change ( Prevent GParted starting stopped Linux Software RAID arrays ) after doing a git pull and I have to object. I don't think it is appropriate to diddle with the system's udev rules like this. Also I have already patched libparted in debian and ubuntu to fix the underlying cause of this problem in version 2.3-14 back in August.
Hi Phillip, Re: Objection to patch: Prevent GParted starting stopped Linux Software RAID arrays Only a runtime override is installed on a ram based file system which is removed when GParted closed. (Should gparted wrapper script be killed the override will be cleared on reboot). GParted already prevents systemd, hal, udisks and devkit-disks from automatically mounting file systems so that their state doesn't change from probing and modification that GParted performs. It seems entirely consistent to extend this to Linux Software RAID arrays to temporarily prevent automatic changes to their busy state. (This allows GParted to reformat a partition containing a member of a stopped array without causing chaos). Putting the change in GParted fixes it for users of all distributions. For these reasons I think the patch is correct. Thanks, Mike
Hi Phillip, Re: Objection to patch: Prevent GParted starting stopped Linux Software RAID arrays What is the nature of your objection to this change? Is there some adverse consequence that we overlooked? In my testing, I did not experience any ill effects while using GParted on Linux software RAIDs, either stopped, or running. Having said that, I have not tested every possible scenario of disk configurations with Linux software RAID. With GParted we try to minimize the chance of any adverse side effects. This implementation is aligned with this goal and with other methods we use as outlined in comment #14. Curtis
For one, it breaks hot plugging raid arrays while gparted is open. In the case of systemd/hal/etc, those are all suppressed using a mechanism intended for that purpose. Udev rules are provided by the distribution and are not supposed to be changed willy-nilly by applications. What distributions other than Ubuntu 13.04 are affected by this? The bug was caused by a relatively recent change I made so I don't think anything else should be affected, and 13.04 reaches end of life in 3 months anyhow.
Hi Phillip, Udev rules fall into 3 categories. Quoting recent udev(7) manual page: RULES FILES The udev rules are read from the files located in the system rules directory /usr/lib/udev/rules.d, the volatile runtime directory /run/udev/rules.d and the local administration directory /etc/udev/rules.d. GParted only puts rules temporarily in the volatile runtime location. From the testing Curtis and I did in comment #7 and #12 GParted / libparted's scanning cause Linux Software RAID arrays to be automatically started on all distributions and all libparted versions, except CentOS 5.9 which had a too old version of udev to contain the relevant rules. Can you point us to the bug and fix you put into libparted in Ubuntu 13.04? Thanks, Mike
In my opinion, breaking hot plugging of RAID arrays while gparted is open is less of a problem than GParted autostarting stopped arrays. This is extremely important if a person was trying to fix a Linux software RAID array. Of course I would advise that the person should not be trying to partition devices with GParted while they are in the act of repairing a RAID. The core of the problem is that potential data loss issues can arise whenever a person has GParted open and they change the status of partitions (mount/unmount, activate/deactivate), or add or remove devices outside of GParted. This is because GParted is unaware of the change. GParted needs full control of the device and partition status while GParted is open. GParted only refreshes the device and partition information on startup, or subsequent refreshes (such as after applying operations). This is one reason why GParted tries to use hal-lock to take out an exclusive lock on all storage devices. When working on the man page a few years back I added the following clause to try to warn users not to change partition status while gparted was running: Quote from http://gparted.org/display-doc.php?name=man-page You can help to reduce the risk of data loss by not mounting or unmounting partitions outside of the gparted application while gparted is running. We could expand on this warning to advise not adding/removing devices while GParted is open too.
My goodness how time flies. It seem my patch that introduced this was applied back in 2010 in upstream parted 2.3, so that explains why it is being so widely seen. It still feels a bit hackish to add a udev rule, but given the prevalence of the problem and the fact that it's in /run, I withdraw my objection.
Thank you Phillip for reviewing these patches and publishing your concerns. The earlier we can catch potential mistakes, the better. Sometimes it's a fine line we tread when deciding on the lesser of two paths that each have undesirable consequences.
This enhancement was included in the GParted 0.17.0 release on December 9, 2013.