|
From: | Riaan van Niekerk |
Subject: | Re: Problem with GPT partition after LUN resized (parted-1.7.0) |
Date: | Tue, 15 Aug 2006 22:41:28 +0200 |
User-agent: | Thunderbird 1.5.0.4 (X11/20060614) |
Darren Lavender wrote:
Following on from my earlier bug report:Problem with GPT partition after LUN resized parted-1.7.0 (platform ia64)I have discovered the root cause and fixed both problem #1 & #2, perhaps the fixes suggested below can be reviewed/considered for inclusion in to the parted/libparted???##### PROBLEM DETAILS #####I observe several problems with parted v1.7.0 after having resized a LUN on ia64 (SLES8):### PROBLEM #1: An exception when parted recognises that the backup GPT header is not in the correct place and tries to move it:........... Assertion (n > 0) at exception.c:112 in function ped_log2() failed.Ignore/Cancel? IgnoreYou found a bug in GNU Parted! Here's what you have to do:This assertion problem is found in command_line_get_ex_opt() ofparted-1.7.0/parted/ui.c and can be addressed via the following patch:royce:~ # diff -Naur parted-1.7.0.old/parted/ui.c parted-1.7.0/parted/ui.c --- parted-1.7.0.old/parted/ui.c 2006-05-15 02:49:53.000000000 -0700 +++ parted-1.7.0/parted/ui.c 2006-08-14 13:50:10.000000000 -0700 @@ -1027,13 +1027,13 @@opt = PED_EXCEPTION_OPTION_FIRST;while (1) { - opt = option_get_next (options, opt); if (strcmp (opt_name, ped_exception_get_option_string (opt)) == 0) break; if (strcmp (opt_name, _(ped_exception_get_option_string (opt))) == 0) break; + opt = option_get_next (options, opt); } free (opt_name); return opt;royce:~ #The problem occurs because we prematurely advance the options, thereby missing the one we're after. After making the above change the assertion error is no longer observed.### PROBLEM #2: Having relocated the GPT headers, I cannot utilise the additional space made available in the resized LUN........So although the header was relocated parted made no attempt to modify the LastUsableLBA field, hence the newly available space is not available for a new partition or resizing. Should this not have been adjusted to 25165790 ?Am I missing some technical reason for why this did not happen or is it simply an oversight/defect?This problem occurs because when the backup GPT is not located at the end of the disk we assume it is corrupt, we could in fact locate it from the data in the first header, but that's a different story. Anyway, when moving the header we simply don't consider the fact that the devicehas grown and that we could utilise the newly allocated space.The code I introduce now gives the user the option of updating the LastUsableLBA so that the space can be utilised, or they can ignore thefact that the disk has changed size and leave the LastUsableLBA alone.The code modified is in: parted-1.7.0/libparted/labels/gpt.c:_parse_header(): royce:~ # diff -Naur parted-1.7.0.old/libparted/labels/gpt.c parted-1.7.0/libparted/labels/gpt.c --- parted-1.7.0.old/libparted/labels/gpt.c 2006-05-15 02:19:34.000000000 -0700 +++ parted-1.7.0/libparted/labels/gpt.c 2006-08-14 13:56:45.000000000 -0700 @@ -612,6 +612,7 @@ GPTDiskData* gpt_disk_data = disk->disk_specific; PedSector first_usable; PedSector last_usable; + PedSector last_usable_if_grown;PED_ASSERT (_header_is_valid (disk->dev, gpt), return 0); @@ -633,11 +634,47 @@ first_usable = PED_CPU_TO_LE64 (gpt->FirstUsableLBA);last_usable = PED_CPU_TO_LE64 (gpt->LastUsableLBA); + +/* Need to check whether the volume has grown, the LastUsableLBA is + normally set to disk->dev->length - 2 - ptes_size, where ptes_size + is the number of entries * size of each entry / sector size. + If the volume has grown, offer the user the chance to use the new + space or continue with the current usable area. +*/+ + last_usable_if_grown + = PED_CPU_TO_LE64 (disk->dev->length - 2 - + ((PedSector)(PED_CPU_TO_LE32(gpt->NumberOfPartitionEntries)) * + (PedSector)(PED_CPU_TO_LE32(gpt->SizeOfPartitionEntry)) / + disk->dev->sector_size));+ + PED_ASSERT (last_usable > first_usable, return 0); PED_ASSERT (last_usable <= disk->dev->length, return 0); + + PED_ASSERT (last_usable_if_grown > first_usable, return 0); + PED_ASSERT (last_usable_if_grown <= disk->dev->length, return 0); + + if ( last_usable < last_usable_if_grown ) { + + if (ped_exception_throw ( + PED_EXCEPTION_ERROR, + PED_EXCEPTION_FIX | PED_EXCEPTION_IGNORE, + _("The disk appears to have grown in size, you " + "can fix the GPT to use the newly allocated space " + "or continue with the current setting? ")) + == PED_EXCEPTION_FIX) { + + + last_usable = last_usable_if_grown; + + } + } + ped_geometry_init (&gpt_disk_data->data_area, disk->dev, first_usable, last_usable - first_usable + 1);+gpt_disk_data->entry_count = PED_CPU_TO_LE32 (gpt->NumberOfPartitionEntries); PED_ASSERT (gpt_disk_data->entry_count > 0, return 0);royce:~ #With this code in place, the user is prompted to update the GPT if the current LastUsableLBA does not match where we think it should be for a volume of this size with gpt->NumberOfPartitionEntries, eg:royce:~/parted-1.7.0 # parted /dev/vgparted/lvol1 GNU Parted 1.7.0Using /dev/vgparted/lvol1 Welcome to GNU Parted! Type 'help' to view a list of commands.(parted) print Error: The backup GPT table is not at the end of the disk, as it should be.This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)?Fix/Cancel? f Error: The disk appears to have grown in size, you can fix the GPT to use the newly allocated space or continue with the current setting? Fix/Ignore? fDisk /dev/vgparted/lvol1: 1887MB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags1 17.4kB 512MB 512MB primary 2 512MB 1536MB 1024MB primary (parted) q Information: Don't forget to update /etc/fstab, if necessary.I have performed some rudimentary testing and the fixes appear to work. Nevertheless, further close review would not be shunned!
hi Darren I patched parted 1.7.0 with your diffs and and compiled parted for i386 and x86_64. It prompts to fix problem #2 (problem#1 was fixed by an earlier patched parted), but then does not fix the problem in all but a very dubious scenario, with unexpected side-effects. I tried the following environments/permutations: * (1) Works (with caveat): parted.i386 on grown Logical volume (I don't have a SAN connected to my 32-bit test host) (1a) fix 1 then fix 2 - (both fix 1 and fix 2 work) (1b) fix 1 then Ignore at fix 2. (fix 1 works). trying fix 2 fails * (2) Fails: parted.x86_64 on SAN * (3) Fails parted.i386 on SAN, with and without linux32 prepended (I copied the binary across to the SAN-attached host, since it is a statically compiled binary) To put in other words: fix 2 will only run if it is run directly after fix 1. on a machine which only has problem 2, fix 2 will not run correctly. (2) and (3) are run against a PT which has problem 2 and requires fix 2 standalone. Minor (cosmetic?) caveats at (1): using your parted.i386 against a logical volume instead of a LUN has the following anomalous behaviour (on my RHEL 4 host): a) read-gpt did not show the backup partition table initially. a patched parted 1.6.9 provided by Red Hat (which contains your code) created a backup GPT but with all values blank (I am passing this info on to them them aswell) b) it removed the backup gpt altogeather (even though it is empty) c) the device nodes for the partition on top of the LV are not created, e.g. /dev/vg_gfs/lun1, etc (and parted/partprobe complains after running the fix) +++++++++++++ ### empty backup partition table created by patched parted 1.6.9 ### fixing problem #1 [gpt-test:/home/riaan/parted-1.7.0/parted]# lvextend /dev/vg_gfs/lun -l +200 Extending logical volume lun to 55.00 GB Logical volume lun successfully resized [gpt-test:/home/riaan/parted-1.7.0/parted]# ./../../ /dev/vg_gfs/lun Signature EFI PART Revision 0x00010000 HeaderSize 92 HeaderCRC32 2153047451 MyLBA 1 Alt-LBA 62914559 FirstUsableLBA 34 LastUsableLBA 62914526 DiskGUID PartitionEntryLBA 2 NumberOfPartitionEntries 128 SizeOfPartitionEntry 128 PartitionEntryArrayCRC32 1045399346 Signature Revision 0x00000000 HeaderSize 0 HeaderCRC32 0 MyLBA 0 Alt-LBA 0 FirstUsableLBA 0 LastUsableLBA 0 DiskGUID PartitionEntryLBA 0 NumberOfPartitionEntries 0 SizeOfPartitionEntry 0 PartitionEntryArrayCRC32 0 [gpt-test:/home/riaan/parted-1.7.0/parted]# ./parted /dev/vg_gfs/lun print Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)? Fix/Cancel? F Error: The disk appears to have grown in size, you can fix the GPT to use the newly allocated space or continue with the current setting? Fix/Ignore? F Disk /dev/mapper/vg_gfs-lun: 59.1GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 17.4kB 2684MB 2684MB primary 2 2684MB 29.5GB 26.8GB primary 3 29.5GB 32.2GB 2684MB primary Information: Don't forget to update /etc/fstab, if necessary. ### backup PT removed [gpt-test:/home/riaan/parted-1.7.0/parted]# ./../../read-gpt /dev/vg_gfs/lun Signature EFI PART Revision 0x00010000 HeaderSize 92 HeaderCRC32 2261563993 MyLBA 1 Alt-LBA 115343359 FirstUsableLBA 34 LastUsableLBA 115343326 DiskGUID PartitionEntryLBA 2 NumberOfPartitionEntries 128 SizeOfPartitionEntry 128 PartitionEntryArrayCRC32 1045399346 ##### I am able to create a new partition in the space ##### made available by fix2: [gpt-test:/home/riaan/parted-1.7.0/parted]# ./parted $LUN unit s print Disk /dev/mapper/vg_gfs-lun: 59.1GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 17.4kB 2684MB 2684MB primary 2 2684MB 29.5GB 26.8GB primary 3 29.5GB 32.2GB 2684MB primary Disk /dev/mapper/vg_gfs-lun: 115343359s Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 34s 5242846s 5242813s primary 2 5242847s 57671646s 52428800s primary 3 57671647s 62914526s 5242880s primary Information: Don't forget to update /etc/fstab, if necessary. [gpt-test:/home/riaan/parted-1.7.0/parted]# ./parted $LUN mkpart primary 62914526s 115343359s Warning: You requested a partition from 32.2GB to 59.1GB. The closest location we can manage is 32.2GB to 59.1GB. Is this still acceptable to you? Yes/No? no Information: Don't forget to update /etc/fstab, if necessary. [gpt-test:/home/riaan/parted-1.7.0/parted]# ./parted $LUN unit s mkpart primary 62914526s 115343359s Warning: You requested a partition from 62914526s to 115343359s. The closest location we can manage is 62914527s to 115343326s. Is this still acceptable to you? Yes/No? Yes Error: Error informing the kernel about modifications to partition /dev/mapper/vg_gfs-lun1 -- Invalid argument. This means Linux won't know about any changes you made to /dev/mapper/vg_gfs-lun1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting. Ignore/Cancel? i Error: Error informing the kernel about modifications to partition /dev/mapper/vg_gfs-lun2 -- Invalid argument. This means Linux won't know about any changes you made to /dev/mapper/vg_gfs-lun2 until you reboot -- so you shouldn't mount it or use it in any way before rebooting. Ignore/Cancel? i Error: Error informing the kernel about modifications to partition /dev/mapper/vg_gfs-lun3 -- Invalid argument. This means Linux won't know about any changes you made to /dev/mapper/vg_gfs-lun3 until you reboot -- so you shouldn't mount it or use it in any way before rebooting. Ignore/Cancel? i Error: Error informing the kernel about modifications to partition /dev/mapper/vg_gfs-lun4 -- Invalid argument. This means Linux won't know about any changes you made to /dev/mapper/vg_gfs-lun4 until you reboot -- so you shouldn't mount it or use it in any way before rebooting. Ignore/Cancel? i Information: Don't forget to update /etc/fstab, if necessary. [gpt-test:/home/riaan/parted-1.7.0/parted]# ./parted $LUN unit s print Disk /dev/mapper/vg_gfs-lun: 115343359s Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 34s 5242846s 5242813s primary 2 5242847s 57671646s 52428800s primary 3 57671647s 62914526s 5242880s primary 4 62914527s 115343326s 52428800s primary Information: Don't forget to update /etc/fstab, if necessary. ++++++++++ tnx Riaan
riaan.vcf
Description: Vcard
[Prev in Thread] | Current Thread | [Next in Thread] |