GNOME Bugzilla – Bug 317262
gparted does not like dmraid /dev/mapper devices
Last modified: 2009-03-26 22:17:09 UTC
Version details: 0.0.8 Distribution/Version: Ubuntu Breezy Forwarded from http://bugzilla.ubuntu.com/show_bug.cgi?id=16268 It seems that gparted does not like working with /dev/mapper devices. I believe it has something to do with the fact that after updating the partition table, it issues an ioctl to ask the kernel to re-read the partition table and fix up the partition devices, but this operation is not supported on /dev/mapper devices. The symtoms that I have seen so far include: 1) Attempting to resise a partition ( NTFS in this case ) simply did nothing. When I clicked apply, it appeared to work for a few seconds, then just stopped with no error message. No changes were made to the disk. 2) If you attempt to create a new partition and format it, the new partition gets created, but the format fails because the ioctl fails and the new partition device does not exist. I had to only add the partition, apply, then run the dmraid utility to re-read the partition table and create the new partition device, then refresh gparted and then format.
send an email about this to the bug-parted mailinglist. You'll hear from me as soon a i know more.
reply from Patrick Leslie Polzer <leslie.polzer@gmx.net> ---------------------------------------------------------------- thanks for the forward! This seems to be an easy fix. I'll take a look ASAP. --------------------------------------------------------- I'll keep you informed.
Created attachment 56672 [details] hdiogetid.c leslie asked: Someone using it (LVM and RAID people) please compile the attached program, run it on a mapper device and post the output. thnks
I ran the program on my raid device and it reported "Inappropriate ioctl for device" As I said before, I believe the problem is gparted relies on the ioctl to ask the kernel to re-read the partition table, and this is not supported on dm devices because the kernel does not interpret the partition table. Instead of using this ioctl, I believe gparted will need to somehow recognize that the device was created by dmraid, and invoke dmraid -ay to redetect the partition table. I am not sure what user mode utility needs to be invoked for LVM.
quick update: after asking leslie about the progress on this one he told me it's on the list for libparted-1.7 . If i have time i might look at it myself, but i can't make any promises :) If you know C you could also provide a patch yourself to speed up te process. Let me know if you need any help with that.
Where do I find "dmraid", or at least a manual page of it? Can anyone give me access to test box with a similar setup?
If you google for dmraid it's the first hit. I may be able to give you access if needed, and I can certainly answer questions.
I got the package now. You proposed running "dmraid -a y" after changes to update partition tables. This won't affect non-RAID users, but is this desirable for every RAID setup out there?
Hrm... actually I suppose just attempting to run dmraid -ay as a fall back to the BLKPRT ioctl should do the trick. If dmraid isn't installed, ignore the error. If you didn't update the partition table on a dmraid device, then it shouldn't do anything by running it, unless they have unactivated raid sets, in which case, those will be activated. I'm not sure if there is an equivalent for LVM.
I don't like the part about activating the user's deactivated devices. I wonder whether anyone would like their deactivated devices to stay that way for any purpose? Without this question answered I hesitate to include a simple blanket "dmraid -ay"... The best solution would be if anyone could provide a patch for detecting which devices need to be updated. It can't be that hard, but it's tedious to develop without direct access to the matter. Maybe you could help out? And yes, there's a pendant for LVM, it's called vgscan. One has to differentiate between LVM 1 and 2, though.
By the way, what's the BLKPRT ioctl? Parted uses BLKRRPART, and I couldn't find an ioctl named thus anywhere in Linux' include files. Does Parted branch into "The kernel was unable to re-read the partition " "table on %s (%s). This means Linux won't know " "anything about the modifications you made " "until you reboot. You should reboot your computer " "before doing anything with %s." with your setup?
Sorry, I meant BLKRRPART then; the one that asks the kernel to read the partition table and update the list of partition devices. This is not supported by the device mapper, so the call fails. It looks like the following command can be used to detect the active raid sets: ~# dmraid -sa *** Active Set name : via_hfciifae size : 144607678 stride : 128 type : stripe status : ok subsets: 0 devs : 2 spares : 0 The actual name of the device is /dev/via_hfciifae and the partitions on it are followed by a number as one would expect. I suppose you can perform some patern matching to decide if the device in question is dmraid volume and if so, invoke dmraid -ay via_hfciifae to reactivate the set after updating the partition table.
Sorry, that was supposed to be /dev/mapper/via_hfciifae.
I think you forgot to answer my last question, or you did answer only implicitly, in which case it is not clear...
Sorry, I am not sure if that is the output that gparted generates because I have not tried to repartition in some time. I am however, sure that the kernel device mapper does not support the BLKRRPART ioctl ( because it doesn't read partition tables in the first place ) and so if that is the message that gparted generates when that ioctl fails, then yes, it should be doing so.
Scheduled for 1.7.1.
1.7.1 has been released, can someone give an update on this? @leslie: sorry i didn't send you an email about the API yet. I'm very busy, although that should never be an excuse for being late ;) i'll try to mail you this weekend.
No fix for this in 1.7.1 yet, sorry (1.7.1 turned out to be a hot bugfix release). I did not forget it, however. It's an important item on Parted's agenda.
i just saw that 1.8.0rc1 was released. Does that one adresses this issue? thnx!
I am interested in fixing this bug, and Leslie has asked me to work on this. As far as I understand, in case of LVM 'vgscan --mknodes' checks for missing device nodes (in /dev/mapper/) for logical volumes, which are part of active volume groups. However somehow the parted front-end does not seem to work with LVM. I am talking about the 1.7.1. Here is what I get http://lists.gnu.org/archive/html/bug-parted/2006-09/msg00028.html I would like to know whether the original bug posted here was referring to RAID or LVM devices specifically or all /dev/mapper devices?
Originally I was refering to raid devices created with the dmraid package. LVM should have similar issues, just a different utility needs called to rescan the partition table.
As far as I know /dev/mapper devices are not usually physical devices. The only uses of /dev/mapper that I've come across are LVM 2, EVMS and dmraid. gparted should actively avoid interacting with LVM and EVMS mapper devices since those will never need repartitioning, they are made up of partitions. With this clarification this update to gparted can focus on only working with dmraid devices. Detecting when a /dev/mapper device is a dmraid device, repartitioning the device (which it does already) and calling dmraid -ay to re-activate already activated devices after they have been repartitioned. See here: http://en.wikipedia.org/wiki/Device_mapper and here: http://sourceware.org/dm/
I use dmraid and i want to partecipe to resolve this bug. But I`m not a good programmer so I can partecipe to test and debugging.I used gparted 0.25 and it did not show my dmraid device. Gparted 0.31 show it but it shows also the partitions as device. If I select the right device (not the partitions) it give at the partition the same name of the device so I cannot do operations from there. The output of fdisk -l for my device is: gianluca@terranova:~/Desktop$ sudo fdisk -l /dev/mapper/isw_cagffbfdfc_raid0 Disk /dev/mapper/isw_cagffbfdfc_raid0: 160.1 GB, 160120176640 bytes 255 heads, 63 sectors/track, 19466 cylinders Units = cilindri of 16065 * 512 = 8225280 bytes Dispositivo Boot Start End Blocks Id System /dev/mapper/isw_cagffbfdfc_raid0p1 * 1 6374 51199123+ 7 HPFS/NTFS /dev/mapper/isw_cagffbfdfc_raid0p2 6375 12749 51207187+ c W95 FAT32 (LBA) /dev/mapper/isw_cagffbfdfc_raid0p3 12750 12762 97657 83 Linux /dev/mapper/isw_cagffbfdfc_raid0p4 12762 19467 53863360+ 5 Esteso /dev/mapper/isw_cagffbfdfc_raid0p5 12762 17625 39062500+ 83 Linux /dev/mapper/isw_cagffbfdfc_raid0p6 17625 17749 1002279+ 83 Linux /dev/mapper/isw_cagffbfdfc_raid0p7 17750 19467 13798486 83 Linux and ls /dev/mapper: gianluca@terranova:~/Desktop$ ls /dev/mapper control isw_cagffbfdfc_raid02 isw_cagffbfdfc_raid06 isw_cagffbfdfc_raid0 isw_cagffbfdfc_raid03 isw_cagffbfdfc_raid07 isw_cagffbfdfc_raid01 isw_cagffbfdfc_raid05 so when I select /dev/mapper/isw_cagffbfdfc_raid0 as device, if i try to format a partition, it try to format /dev/mapper/isw_cagffbfdfc_raid0 and not /dev/mapper/isw_cagffbfdfc_raid05 Instead, if I select a partition as device, the name of partition is correct and If I try to format but the program has an error. When It rescans the devices, the partition that I tried to format result as unallocated space. P.S. I can do partition with fdisk and I can format with mkfs tools, but gparted is integrated in certain distribution`s installer and I cannot do a normally and simple installation. So I want to help, to do more simple install in the future
As of 0.2.5 in ubuntu at least, the situation has gotten worse. Now gparted doesn't even list the dmraid devices in the drop down list. Manually running gparted with the correct device as a command line argument causes gparted to show the partition table as it did before, but it still can't mount the volumes or update after changes to the partition table.
The ubuntu live running gparted 0.2.5 is the best way you can try for successful disaster. Does Ubuntu team care of their users ? No other comment to give about this point.
(In reply to comment #25) > The ubuntu live running gparted 0.2.5 is the best way you can try for > successful disaster. Does Ubuntu team care of their users ? > > No other comment to give about this point. > I can not understand this comment nor see that it has anything at all to do with this bug report.
(In reply to comment #26) > (In reply to comment #25) > > The ubuntu live running gparted 0.2.5 is the best way you can try for > > successful disaster. Does Ubuntu team care of their users ? > > > > No other comment to give about this point. > > > > I can not understand this comment nor see that it has anything at all to do > with this bug report. > So I may have misunderstood this "As of 0.2.5 in ubuntu at least". Excuse-me.
This is still an issue in Ubuntu's Intrepid Ibex release; dmraid devices are not listed in the drop down box of gparted.
Thank you Phillip for confirming this problem in Ubuntu's Intrepid Ibex release. Intrepid used GParted v0.3.8 which is fairly recent. If I recall, Ubuntu Intrepid uses parted version 1.8.9 which hasn't been officially released as of yet. So Intrepid has a very recent version of parted and it would appear that this issue was not resolved in parted/libparted. I have some thoughts on how to address this problem inside GParted, but unfortunately do not have access to a computer set up with these dmraid (fake raid) devices. Hence to fix the problem I either need access to such a computer set up, or someone to help test out my code changes and report back. Would you be in a position to do either of these, or know someone who might be able to do this?
I can test, and I can help you set up your system to fake it if you want. You can compile dmraid with a test option and play with dmsetup to create dm devices that look like an empty hard disk with just the metadata at the end and dmraid will recognize them and activate them as a raid set. If you want to talk, you can find me as psusi on the freenode irc network.
If dmraid devices can be simulated that would be a great boon to developing a solution. :-) Would you be able to point out the steps on how to fake the dmraid devices? That way I could work towards a solution without having to constantly send code back and forth between you and me for testing. Of course if you have a read dmraid setup, actual testing would be most useful as well. I too am often on the FreeNode IRC network in #parted, or on GIMPNet in #gparted as gedakc.
Hi Phillip, Do you have a list of steps to create and test dmraid for a person without dmraid hardware?
Recently I acquired the hardware to set up a motherboard BIOS based raid (FAKE RAID). By experimenting with gparted/parted/dmraid, I have discovered the following two anomalies: ANOMALY 1) Libparted inserts the letter 'p' between the device name and partition number. For example with my "TestRaid0" raid setup: /dev/mapper/isw_fbjjcbebc_TestRaid01 is the name returned by ls -l command. /dev/mapper/isw_fbjjcbebc_TestRaid0p1 is the name returned by libparted. ANOMALY 2) The "dmraid -ay" command does not remove the file system entry when a partition is deleted. As stated by Phillip in comment #4, if a partition is created using parted/gparted, the "dmraid -ay" command does seem to force creation of an entry in the /dev/mapper directory for the partition device name. The opposite situation does not appear to be true. When a partition is deleted using parted/gparted, it appears that the "dmraid -ay" command does not remove the /dev/mapper partition device name entry in the file system.
An interesting addition to ANOMALY 1 above: If I name the raid "TestRaid" without the trailing "0", then libparted does not add the extra "p" between the device name and the partition number. For the first partition on my "TestRaid" raid setup: /dev/mapper/isw_cjdcbiheed_TestRaid1 is the name returned by ls -l command. /dev/mapper/isw_cjdcbiheed_TestRaid1 is the name returned by libparted.
The word "dmraid" has been added to the title of this bug. GParted is a partition editor, and as such it makes sense for GParted to support dmraid (Fake RAID) devices. In my opinion, it does not make sense to support any other current /dev/mapper/* devices because they are not partitionable in the traditional sense. /dev/mapper Device Supports Partitions? ------------------ -------------------------------------- Crypt (dm-crypt) I don't think so. Fake RAID (dmraid) Yes LVM No (but does support logical volumes) SW RAID (mdadm) No This also agrees with the Richard's statement in comment #22 above.
Good news! I have devised a solution to add dmraid support to GParted. :-) Now I am looking for help testing it. A tarball is available at: http://gparted.sourceforge.net/gparted-0.4.3-dmraid-beta1.tar.bz2 The solution requires that the following commands or packages are installed: dmsetup dmraid kpartx Your assistance with testing, and your feedback would be much appreciated. Following is some background information: All of my development and testing has been using an Intel Software Raid (isw). KNOWN PROBLEMS: 1) The mount status of partitions is not detected by GParted. Hence operations that should not be permitted on mounted partitions are currently available. * WARNING* Do not perform operations on mounted partitions. 2) FAT16 and FAT32 file systems show an exclamation mark in the display. This is because GParted uses dosfsck to determine the number of used sectors. Unfortunately, dosfsck does not appear to work with /dev/mapper devices. :-( 3) Resizing an extended partition in an MSDOS partition table half works. a) You can successfully shrink the partition from the right. An error message is displayed, but the partition is resized. b) You can not successfully shrink the partition from the left. COMMANDS USED IN SOLUTION: * To list the active dmraid devices: dmraid -sa -c * To ensure that the /dev/mapper dmraid device entry exists: dmraid -ay -v -p {dmraid_prefix} * To ensure that the /dev/mapper dmraid partition entries exist: kpartx -a -v /dev/mapper/{dmraid_name} * To delete /dev/mapper dmraid entries: dmsetup remove /dev/mapper/{dmraid_device_or_partition_name}
*** Bug 556114 has been marked as a duplicate of this bug. ***
*** Bug 351126 has been marked as a duplicate of this bug. ***
OK, good timing on that. I just got back today. Got a new build tomorrow so may not get to this right away but, in the meantime, what precisely do you want me to check? I.e., I'm making the (possibly wild) assumption that I will be able to build everything and it will recognize NVRAID 0 of 3 SATA1 disks as one logical drive. While I do not wish to destroy the data on those three drives, the data have become redundant as of today and can be 'played with' so to speak. So what else do you want me to test?
Thanks for the offer of help with testing. I have only tested with an Intel Software RAID. If I recall, you have NVIDIA RAID so it would be good to know if the code works on it too. It would be great if you could test the following: 1) Does gparted recognize your /dev/mapper/... RAID drive? NOTE: That individual /dev/sd[a|b|c|d] will still be shown as well. 2) Can you create / resize / delete a partition? 3) Can you move / copy a partition? You might want to try a small partition so it doesn't take too long. 4) If you have drive that you can afford to wipe clean, can you create a new partition table?
The problem with incorrectly detecting mounted partitions should now be fixed. :-) If you would like to help test dmraid support in GParted, please see the following forum post: http://gparted-forum.surf4.info/viewtopic.php?pid=19714
This enhancement will be included in the next release of GParted (0.4.4) which is planned for April 2nd, 2009. Closing this bug.