GNOME Bugzilla – Bug 566935
Unable to expand GPT partition when growing RAID
Last modified: 2012-02-22 06:08:44 UTC
Please describe the problem: 've tried twice now to resize a partition on a Areca 1220 RAID volume from 2.6 TB to 3.4 TB. The first time I used the latest Gparted Live CD, which ran fine and recognized the volume, but when it went to resize, simply kept the size the same as the existing. In the end there was no damage, but it took a long time and no work was done except two esfcks. I did not save the output from that operation, unfortunately. Since the volume I'm resizing is not the boot volume, I also tried unmounting it after boot and using the latest gparted from apt-get. I interrupted the operation since it was on track to do the same thing as the first attempt, namely keep the sizes the same as the original and just go through the motions. Here is the output from that attempt: ------------------------------- GParted 0.3.8 Libparted 1.8.8 Grow /dev/sdb1 from 2.64 TB to 3.55 TB 00:00:20 ( ERROR ) calibrate /dev/sdb1 00:00:00 ( SUCCESS ) path: /dev/sdb1 start: 34 end: 5664061406 size: 5664061373 (2.64 TB) calculate new size and position of /dev/sdb1 00:00:00 ( SUCCESS ) requested start: 34 requested end: 7617171554 requested size: 7617171521 (3.55 TB) new start: 34 new end: 5664061406 new size: 5664061373 (2.64 TB) check filesystem on /dev/sdb1 for errors and (if possible) fix them ( EXECUTING ) e2fsck -f -y -v /dev/sdb1 ------------------------------- Machine info: Ubuntu/Debian, Poweredge 1800 with Areca 1220 RAID card uname -a: Linux saba 2.6.22-4-686 #1 SMP Tue Feb 12 16:29:32 UTC 2008 i686 GNU/Linux -------------------------------- Again, this was an aborted attempt, so that might explain the ( ERROR ) marker. Any ideas? I've done volume expansion before successfully using a far more manual, tedious, and error prone way. I'd love to do it automatically, if possible. NOTE: Although the above output was obtained using 0.3.8, identical results happened with the 0.4.1 Live CD Steps to reproduce: 1. Have Areca 1220 RAID card 2. Attempt to resize 2.6 TB partition to greater size 3. Actual results: Expected results: Does this happen every time? Yes Other information: EDIT: I've done some more research and it looks like you may have hit a bug. GParted calls the libparted function ped_disk_set_partition_geom() between the requested start/end/size notice and the new start/end/size notice. It appears that the bug is in the libparted library that GParted calls. Would you be able to open a bug for this? http://gparted.sourceforge.net/bugs.php
Thank you for reporting this problem. Would you be able to report back with the output from the following command? parted /dev/DEVICE print unit s print unit chs print Where: /dev/DEVICE is the the device name of your RAID device (e.g., /dev/sdb)
saba:~# df -h Filesystem Size Used Avail Use% Mounted on ... /dev/sdb1 2.6T 2.6T 65G 98% /home ... saba:~# parted /dev/sdb print unit s print unit chs print Warning: Not all of the space available to /dev/sdb appears to be used, you can fix the GPT to use all of the space (an extra 1953124352 blocks) or continue with the current setting? parted: invalid token: unit Fix/Ignore? i Model: Areca ARC-1220-VOL#01 (scsi) Disk /dev/sdb: 3900GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 17.4kB 2900GB 2900GB ext3 primary saba:~#
I'd guess that warning is a big hint about the problem, but I'll resist the urge to re-run and choose fix in hopes that I can help you mend any bugs this glitch might be triggering.
You are right about the big hint. I can see how the problem arose. Following is a description of the problem, a possible solution, and a request. PROBLEM The crux of the problem is that the GUID Partition Table (GPT) stores the ending Logical Block Address (LBA) of the disk when it is created. Since you have added more disk space to the RAID, the GPT is still unchanged and hence limits actions to within its definition of the end of the disk. More specifically, in the GPT there is an entry at offset 32 bytes (called Backup LBA) that is always set to the last Logical Block Address (LBA) on the disk. A backup copy of the GPT is also stored at this Backup LBA minus 34. See following URL for a description of GPT: http://en.wikipedia.org/wiki/GUID_Partition_Table POSSIBLE SOLUTION The challenge (as I see it) to make the added disk space usable is twofold: A) to make a copy of the existing GPT at the new end of the disk, and B) to set the Backup LBA in both copies of the GPT to the new end of the disk. REQUEST 1) Would you able to post a screen shot of GParted with the View Device Information pane open? This will show if the Device Information has the old disk size, or the new disk size. 2) When do you need this RAID up and running with the extra space? If you need it soon, then I would suggest you backup your data, and a copy of the GPT before trying the parted fix option. That way we should be able to reconstruct it if something goes wrong. Otherwise to fix the code I will need time to review the both the parted and gparted code to see what options are available for detecting and fixing this situation.
Created attachment 126080 [details] Requested screeshot of gparted Requested screenshot
1) Would you able to post a screen shot of GParted with the View Device Information pane open? Yes, see above. 2) When do you need this RAID up and running with the extra space? I'm not in a great hurry. I'd really much rather GParted get fixed to seamlessly handle this problem, especially since I've already had GParted not quite work once before, and I'll likely desire it again in a year or two when I go to add the next drive and I've forgotten all this again. I'm happy to help test as best I can. I will be glad to back up my GPT if a pointer is given so I can see how to do it.
Thanks for the screen shot. It looks like GParted is seeing the whole drive, and not the reduced size indicated by the GUID Partition Table (GPT). To make a backup of the GPT, you can use the dd command. WARNING: Be very careful that you type in the "dd" command correctly. A mistake can seriously impact your ability to recover data. For example, to make a backup of the GPT on /dev/sdb: dd if=/dev/sdb of=gptbackup.bin bs=512 count=34 Restoring the GPT is simply a matter of reversing the input and output files. Question: 3) Are you able to compile and run GParted from source code? This will be needed to test any fix that I create for this problem.
3) Are you able to compile and run GParted from source code? This will be needed to test any fix that I create for this problem. ----------- I tried to do this when I was scolded in the original forum thread for running 0.3.8, and am stuck in library problems at the moment. I will detail them shortly in another post here.
Did you read the README file? It describes many of the dependencies that are required and how to install them on ubuntu and fedora. You will need the development libraries for libparted to be able to compile.
Hi Steven, While surfing the web I found a way to recreate this problem, so now I can simulate the addition of extra disk to a volume with a single file. :-) The steps to recreate the problem are: # create an image dd if=/dev/zero of=test.img bs=1M count=100 # create a gpt on it parted test.img mklabel gpt # increase the image size dd if=/dev/zero of=test.img bs=1M count=100 seek=100 # trigger the problem parted test.img print # Press F to have parted Fix the problem If/when you decide to fix the problem with parted, make sure you are using a recent version like 1.8.8 or higher. If I recall there were some GPT problems in earlier versions of 1.8.x.
Curtis: I'm glad you've made progress without my direct help - thank you for your efforts. I'm not clear if you've patched gparted or not to handle the problem I've encountered?
GParted has not been patched to handle this problem. It will be more difficult than I initially thought to address this problem. At least I haven't thought of how to do elegantly do it just yet. ;-( That's why I thought I thought I'd let you now that I can at least recreate the problem without having the RAID card and lots of disk. The Parted program does have a fix for this problem. You can still use GParted to resize the partition, but only after you first run parted to fix the GPT / disk size anomaly. There have been many bug fixes in GParted since version 0.3.8, so I would recommend you upgrade to the latest version before starting the resize. And as always I advise you to have a backup of your data in case anything goes wrong.
I am in the same boat as the author. I'm a linux noob, running ubuntu 8.10, with an Areca 1220. I created a Raid 6 array using 6 1TB drives, and I went to add another 1 tb. I was able to use the areca card to add the drive, then reinitialize the volume. Once this was done Gparted 0.4.2 could see 5000.00 gb was available, but was not able to successfully expand the drive. Hopefully you all don't mind me pasting the following process of what occurred. --------------------------------------- GParted 0.4.2 Libparted 1.8.9 Grow /dev/sda1 from 3.64 TiB to 4.55 TiB 03:08:44 ( SUCCESS ) calibrate /dev/sda1 00:00:00 ( SUCCESS ) path: /dev/sda1 start: 34 end: 7812499422 size: 7812499389 (3.64 TiB) calculate new size and position of /dev/sda1 00:00:00 ( SUCCESS ) requested start: 34 requested end: 9765608264 requested size: 9765608231 (4.55 TiB) new start: 34 new end: 7812499422 new size: 7812499389 (3.64 TiB) check file system on /dev/sda1 for errors and (if possible) fix them 01:35:58 ( SUCCESS ) e2fsck -f -y -v /dev/sda1 Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information 49405 inodes used (0.02%) 2655 non-contiguous inodes (5.4%) # of inodes with ind/dind/tind blocks: 32462/6742/169 516526960 blocks used (52.89%) 0 bad blocks 232 large files 46166 regular files 3230 directories 0 character device files 0 block device files 0 fifos 0 links 0 symbolic links (0 fast symbolic links) 0 sockets -------- 49396 files e2fsck 1.41.3 (12-Oct-2008) resize/move partition 00:00:00 ( SUCCESS ) new and old partition have the same size and position -- skipping this operation check file system on /dev/sda1 for errors and (if possible) fix them 01:32:46 ( SUCCESS ) e2fsck -f -y -v /dev/sda1 Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information 49405 inodes used (0.02%) 2655 non-contiguous inodes (5.4%) # of inodes with ind/dind/tind blocks: 32462/6742/169 516526960 blocks used (52.89%) 0 bad blocks 232 large files 46166 regular files 3230 directories 0 character device files 0 block device files 0 fifos 0 links 0 symbolic links (0 fast symbolic links) 0 sockets -------- 49396 files e2fsck 1.41.3 (12-Oct-2008) grow file system to fill the partition 00:00:00 ( SUCCESS ) resize2fs /dev/sda1 resize2fs 1.41.3 (12-Oct-2008) The filesystem is already 976562423 blocks long. Nothing to do! libparted messages ( INFO ) Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 1953124864 blocks) or continue with the current setting? Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 1953124864 blocks) or continue with the current setting? ------------------------------------- After this, I started noticing issues with parted ------------------------------------- (parted) check Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 1953124864 blocks) or continue with the current setting? Fix/Ignore? Fix Partition number? 1 Error: File system has an incompatible feature enabled. Compatible features are has_journal, dir_index, filetype, sparse_super and large_file. Use tune2fs or debugfs to remove features. ------------------------------------- root@storage:~# mke2fs -n -S /dev/sda1 mke2fs 1.41.3 (12-Oct-2008) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 244146176 inodes, 976562423 blocks 48828121 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=0 29803 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848, 512000000, 550731776, 644972544 root@storage:~# e2fsck -b 32768 /dev/sda1 e2fsck 1.41.3 (12-Oct-2008) STORAGE was not cleanly unmounted, check forced. Pass 1: Checking inodes, blocks, and sizes ------------------------------------- This is where I stand at the moment. It has not been a fun week. Any suggestions would be greatly appreciated, I just hope e2fsck is able to fix the problem with the array so I can try to expand it correctly. Thank you Gary
I've spent a second weekend messing with this and other various tools, all the recent versions of resize2fs, mkfs.ext3 and parted. It seems that ubuntu is not ready to support large filesystems above 4 tb. Whether its the GUI or command line, they all have issues resizing above 4 or 5 terrabyates once the array is created. I've tried to remove the ext3 journal and resize it as ext2 as recommended elsewhere, and once again ran into the superblock or "incompatible" feature issue. I'll be switching to another OS with utilities that can resize without error, so no need to reply to the above message. Thank you
*** Bug 640956 has been marked as a duplicate of this bug. ***
Hey Curtis, why is the libparted exception not being propagated through gparted? The user should get a pop up with that warning prompting them to fix the partition table. If they answer yes, then libparted takes care of it.
Hi Phillip, that is a good question. I have tried to come up with a way to graphically prompt the user when this exception occurs, but have not discovered how to do this yet. The problem I encountered is that the libparted C error handler is set in the GParted_Core.cc, but I have been unable to open a graphical prompt from there to ask the user how to handle the error. See ped_exception_handler in http://git.gnome.org/browse/gparted/tree/src/GParted_Core.cc#n3183
Created attachment 204644 [details] [review] libparted exception messagebox patch Here is my current patch to show a pop up message box on a libparted exception. This allows you to choose to fix the gpt not using the whole disk error ( and any other errors ).
Phillip, this might sound like a dumb question but I hope you will humour me. Should we also have a gdk_threads_leave and gdk_threads_enter around the usleep in Dialog_Progress::on_signal_show()? Also I found one very, very minor spelling mistake in the commit message. s/model dialog/modal dialog/
Renaming title of bug from: Unable to expand Areca RAID partition from 2.6TB to 3.4TB to: Unable to expand GPT partition when growing RAID
Either that, or it should be refactored to not use a nested main loop.
Phillip, I kind of thought so too. Since this feature is big improvement, at least for those growing RAID disk setups, I would like to get this in the next release. I realize that refactoring is a big task, so perhaps we should proceed with wrapping gdk_threads_leave and gdk_threads_enter around the usleep for now. Did you want to do this and submit a new patch? If not then I can add the code and include it in your patch.
Sure, here goes.
Created attachment 204840 [details] [review] libparted exception messagebox patch
Phillip, your updated patch is much appreciated. :-) The patch gracefully handles the following situations: - GPT when RAID has been grown (pop-up with fix/ignore shown) - Disk with no partition table (no pop-up - only noted in libparted msgs) - Disk with overlapping partitions (no pop-up - only noted in libparted msgs) - Disk with no problems (no pop-up - no notes in libparted msgs) I have successfully tested the patch on Ubuntu 10.04, 11.04, and Fedora 16. The patch in comment #24 has been committed to the Gnome git repository for inclusion in the next release of GParted. The relevant commit can be viewed at the following link: http://git.gnome.org/browse/gparted/commit/?id=a1f843e74ae2be98a146c5b77f3a4e0c2f4ea80a
This enhancement has been included in GParted 0.12.0 released on February, 21, 2012.
ok, thank you all very much