GNOME Bugzilla – Bug 524948
1 Terabyte partition limit
Last modified: 2008-04-22 13:43:11 UTC
Please describe the problem: If partitioning a device is at the 2 TB capacity. Gparted complains: "A partition cannot have a length of -1 sectors." (can y'all say signed integer? knew your could!) I tried allocating a single partition, and multiple partitions, and it all works until the sum of the partitions is >= 2TB. Then the complaint always arrives. The problem is purely in the GUI. can partition without issues using gnu-fdisk. Using a Drobo for this, which presents, at minimum, a virtual 2 TB unit. Steps to reproduce: 1. obtain a really huge disk :-) un-partitioned. Fire up gparted. 2. create any combination of partitions >= 2TB 3. Add... Actual results: I get a dialog "Could not add this operation to the list" with the contents: "A partition cannot have a length of -1 sectors." Expected results: I would expect it to create the partitions without complaining, as fdisk does. Does this happen every time? yes. Other information: done with ubuntu hardy heron, all stock.
Peter, thank you very much for this detailed bug report. I will look into this problem and report back.
GNU Parted also appears to have an open bug regarding disks larger than 2 TeraBytes. http://parted.alioth.debian.org/cgi-bin/trac.cgi/ticket/185 GParted uses libparted for partition and device detection and manipulation.
that other bug looks like a different problem. My virtual 2 TB device gave the errors reported in the initial submission, when using gparted. I partitioned it with parted, that comes with *ubuntu hardy heron.. as follows: parted -i /dev/sdd mklabel gpt mkpart ext2 0 100% quit result: root@alu:~# parted -i /dev/sdd GNU Parted 1.7.1 Using /dev/sdd Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Disk /dev/sdd: 2199GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 17.4kB 2199GB 2199GB ext3 (parted) This same operation fails, with the messages indicated in the initial report, when attempted using gparted. observations: -- I can´t really test > 2 TiB. only ´==´ -- Even if there is something broken with parted somewhere, there is something additionally broken in gparted, for it to give this error when parted doesn´t.
Thank you for the clarification Peter. This one has me a little puzzled. The logic within GParted requires that signed values are used. Still, this should not be a problem because the storage variables are defined as long long. This takes 8 bytes of storage (8 bytes x 8 bits = 64 bits) on my computer and I'm running 32 bit Kubuntu Gutsy Gibbon. A 2 TB number (2 ^ 31 = 2147483648) is well within the limit as the range should theoretically go as high as 2 ^ 63 for a signed long long integer. I wonder what the size of a long long is on your computer? Would you be able to try to compile the following snippet of code, and run it on your computer? testlonglong.cc ---------- begin code ---------- #include <iostream> using namespace std; int main() { long long aval; cout << "Size of (aval) is " << sizeof(aval) << endl; } ---------- end code ------------ Compile the code with: g++ testlonglong.cc Run the code with: ./a.out The results from my computer are: Size of (aval) is 8
I'm running 32-bit intel Kubuntu Hardy Heron. root@alu:/tmp# g++ -o kk kk.C root@alu:/tmp# ./kk Size of (aval) is 8 root@alu:/tmp#
Thank you for the quick response. A size of 8 bytes confirms that the storage size of the variable shouldn't be a problem. Perhaps there is some faulty math in trying to use the "Round to Cylinder" function when creating a partition. Would you be able to provide the following from GParted's View -> Device Information menu? Size, Heads, Sectors/Track, Cylinders, and Total Sectors Also would you please try de-selecting "Round to Cylinders" when you create the partition? That should bypass the rounding calculations, and provide more information to help narrow down the location of the bug.
Size: 2.00TiB Path: /dev/sdd DiskLabelType: gpt Heads: 255 Sectors: 63 Cylinders: 267349 Total Sectors: 4294961685 when I ask for information about the existing partition created with parted, it has a warning triangle (unable to detect file system.) right click for information gives /dev/sdd1: un-known filesystem type. First sector: 34 Last Sector 4294967126 Total Sectors: 4294967093 Please note that it reports 5611 more sectors in the partition than in the whole devices 'Total Sectors'. If, in the GUI I then delete, and re-create with 'round to cylinders' unchecked, it creates the partition with a size -512.00B when I click apply, it complains about an empty partition. I exit gparted, and re-created the partition with parted via: mkpart ext2 0 100% quit and then re-mounted the file system with no data loss.
Thank you for the detailed information, and trying the partition creation with "round to cylinders" unchecked. Your note about the partition having 5611 more sectors than the device's total sectors is particularly interesting. I can see that I will have to look deeper into this problem. I will let you know if I need more information and what I find.
Following is a description of the continuing investigation, and a request for more information. INVESTIGATION To probe devices, the library function ped_device_probe_all() is called. To retrieve each device found, the ped_device_get_next() function is used. This returns a data structure that includes much device information including a structure called PedCHSGeometry. This structure contains the following data fields: int cylinders int heads int sectors This is the information that GParted uses to report the cylinders, heads, and sectors in the Device Information window. The Total Sectors is calculated by GParted as cylinders * heads * sectors. This all appears well and good. Next I looked at how the existing partition information is passed to GParted. For each device, GParted loops through the partitions using the library function ped_disk_next_partition(). This function returns a data structure with partition information including a structure called PedGeometry. This structure contains the following data fields: PedDevice * dev PedSector end PedSector length PedSector start The first element is a pointer to the device where the partition lives. The other three elements indicate information about the partition. The definition for PedSector is: typedef long long PedSector // We can address 2^63 sectors. GParted uses these start and end values from libparted for it's partition information. Since GParted uses libparted to determine both the device geometry and the partition geometry, it would appear that any discrepancies in these raw values would originate in libparted. This still doesn't explain the reason why GParted pops up an error in the GUI. REQUEST Would you be able to run the following command on your drive with the 2 GB ext2 partition? I'd like to see what it reports back. parted /dev/DEVICE print unit s print unit chs print
Correct, the request should read 2 TB ext2 partition :-)
root@alu:~# parted /dev/sdd print unit s print unit chs print Disk /dev/sdd: 2199GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 17.4kB 2199GB 2199GB ext2 Disk /dev/sdd: 4294967159s Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 34s 4294967126s 4294967093s ext2 Disk /dev/sdd: 267349,86,56 Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 267349,255,63. Each cylinder is 8225kB. Partition Table: gpt Number Start End File system Name Flags 1 0,0,34 267349,86,23 ext2 Information: Don't forget to update /etc/fstab, if necessary. root@alu:~#
Hi Peter, Thank you again for the above information. I believe that I may have found the source of the bug. It is some integer (storage size 4 byte) math used in GParted with the partition creation dialog box spinbuttons. Would you be able to test the new fix? Instructions Follow: ------------------- I have placed a copy of the latest GParted code at: http://gparted.sourceforge.net/gparted-0.3.6-svn.tar.bz2 To compile it on Ubuntu, you will need to install at least the following dependencies (which themselves may call other dependencies): e2fsprogs uuid uuid-dev gnome-common libparted-dev libgtkmm-2.4-dev You can install them with sudo aptitude install e2fsprogs uuid uuid-dev gnome-common \ libparted-dev libgtkmm-2.4-dev To compile the code, perform the normal steps of extract (tar -xvjf filename) ./configure make The GParted executable will be in the src subdirectory. You can run it with sudo src/gparted Regards, Curtis
Confirmed, all the negative numbers and failure dialog are gone. It works. Great stuff! In the main display though, it still says 'unknown in the file system type column. btw, the device is still smaller than the partition
Great! Thank you Peter for all your work and testing. Following is another request, and a responses to the 'unknown' file system, and size discrepancy: REQUEST I believe the original problem reported would occur for partition sized of 1 TB or greater. Would you be able to try creating a partition of perhaps 1.1 TB to see what happens with the reported 0.3.5 version of GParted? FILE SYSTEM RESPONSE From Comment #11, I can see that Parted did not recognize the file system type because there is a blank entry under the "File System" column. Parted uses libparted for partition and device detection and manipulation. Hence there appears to be a bug within Parted. Bug reports for Parted can be found at: http://parted.alioth.debian.org/cgi-bin/trac.cgi/report From a scan of the bugs reported for Parted, I didn't not observe a report of this problem. Would you be able to follow up with the Parted team regarding the file system not being recognized? SIZE DISCREPANCY RESPONSE Note that the discrepancy between the device size and the partition size is within the size of a cylinder. A cylinder size is calculated as head * sector or 255 * 63 = 16065 in this case. I will investigate to see if I can find the origin of this discrepancy.
REQUEST: confirmed that 1.2 TB partition creation with the old gparted triggers the problem. so the premise / title of the bug report is fundamentally misleading... oops! FILE SYSTEM RESPONSE: parted bug report 191 submitted. http://parted.alioth.debian.org/cgi-bin/trac.cgi/ticket/191 SIZE DISCREPANCY: ok!
Thank you again for your assistance with this bug Peter. To reiterate, the problem occurs for partition creation and resizing of partitions greater than or equal to 1 TeraByte. I will update the title accordingly. With this bug fix applied, partition size is limited is just less than 1024 TeraBytes due to the maximum value of signed 4 byte integer. This may or may not become a problem later depending upon how fast 64 bit operating systems are adopted. The fix for this bug has been commmited to the Gnome repository for inclusion in the next release of GParted. Since my preference is to track a single bug under each heading I will close this bug. Peter, would you be able to create new bugs with appropriate titles for the 'unrecognised' file system for partition sizes over (some value), and device versus partition size discrepancy? Regards, Curtis
*** Bug 463684 has been marked as a duplicate of this bug. ***
Thank you for changing the title, that will save me from ever lasting shame ;-) http://bugzilla.gnome.org/show_bug.cgi?id=529313 - about size discrepancies submitted. http://bugzilla.gnome.org/show_bug.cgi?id=529315 - about inability to identify file system type submitted.
Hi Peter, Thank you for creating those new bugs. I've got them on my todo radar :-) Curtis