Modify

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#1177 closed bug (fixed)

Support big disks (>2 TB)

Reported by: matthijs Owned by:
Priority: normal Milestone: Firmware 2.3.7.0
Component: fon-base-firmware Version: 2.3.7.0 beta3
Severity: major
Cc: Hardware: both

Description

In r1983 (2.3.7.0 beta2), support for large block devices was enabled in the kernel. However, it seems this is not enough to properly support > 2TB disks on the Fonera, there are still errors (reading beyond end of device IIRC).

It would be nice if this could be fixed for 2.3.7.0, to supplement the change in r1983.

Attachments (0)

Change History (13)

comment:1 Changed 7 years ago by matthijs

  • Status changed from new to confirmed

On the blog, a user reported that GUID partition tables (GPT) do not work. He suggested they need to be enabled in the kernel, but they are already (CONFIG_EFI_PARTITION).

I was under the impression that > 2TB disks were forced to use GPT and that by connecting my 3TB disk to my Fonera I had tested GPT was working (the actual filesystem on the disk didn't work, though), but it seems this assumption is wrong. Closer inspection reveals that my 3TB disk is still using the msdos partition table layout and I suspect this is possible because the disk uses 4Kbyte physical sectors (instead of the common 512-byte sectors) and apparently the LBA numbers in the partition table are interpreted as 4K sectors.

This 4K sector business is probably the cause of the problems with big disks, possibly the kernel is handling them wrongly. I thought there was already some fix committed for 4k-sector-disks, but I can't find it right now (so I might be imagining things...).

In any case, here's an interesting read on big disks and Linux (only partly relevant, though): http://lwn.net/Articles/377895/

comment:2 Changed 7 years ago by fbertrand@…

Hi, I am the user from the forum. I am using a 3TB disk with 2.3.7.0 beta3. This are my results:

  • GPT partition table, one single 3TB ext3 partition -> "partition table not recognized" (I can't explain this if the kernel is compiled with GPT support).
  • msdos partition table, one single 3TB ext3 partition -> "attempt to access beyond end of device" (as expected, thus the need for GPT).
  • msdos partition table with two ext3 1.5TB partitions -> works fine (as expected because the individual partitions are smaller than the limit of 2TB).

comment:3 Changed 7 years ago by fbertrand@…

One more thing: in case 3 (msdos with two ext3 1.5TB partitions), everything works fine as far as I can tell but the free space reported in the web interface is incorrect. However from the command line ("df -k"), the free space reported is OK.

The article that you mention is quite old. Recent kernels support 4k-sector drives just fine (since kernel 2.6.31 I think). "parted" will even align the partition correctly in both msdos and GPT partition tables. See http://www.seagate.com/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/

comment:4 Changed 7 years ago by matthijs

Thanks for the additional details.

As for the third case: If the problem is indeed with mixing up 4k sectors with 512-byte sectors, it doesn't make sense that two 1.5 TB partitions do work. This suggests that there is some problem with the length of the partition, not with reading the partition table. However, I do see that when using LBA addressing in the partition table instead of CHS addressing, the partition is specified as start + length instead of start + end, so if the partition table could somehow switch back to 512-byte sectors when using 1.5TB partitions (but AFAICS, the sector size is detected from the disk, not stored in the partition table...).

About the free space, is the free space reported wrongly, or is the disk size wrong? IIRC the free space is taken as an absolute value from df, and then converted to a percentage based on the size of the block device or something like that (mountd detects the size of the device, luci then queries df for the free size).

As for 4K sector support in recent kernels: Don't forget that the Foneras are running on 2.6.21 and 2.6.26, so we might need to backport some patches, then...

comment:5 Changed 7 years ago by fbertrand@…

Me again. Summary of my status. I have settled on the following working configuration:

  • msdos partition table.
  • One 2TB partition.
  • One 1TB partition.

(note: two 1.5TB partitions also work)

I have created this configuration by plugging the drive in a Linux box and using "parted". Then I have connected the drive to the fonera and I have activated the Windows Network Shares. I have mounted the drives remotely, one from a Mac Snow Leopard and the other partition from a Linux box. I have been using these remote shares extensively in the past couple of days, including making a very large backup, and everything works just fine: the shares are mounted fine and the reported disk size and free space, as seen in the Mac and Linux boxes are correct.

Also, if I connect the fonera using ssh, I can see that "df" reports the correct sizes. The only place where the reported size is bogus is in the fonera web interface (it reports 14TB and 7TB instead of 2TB and 1TB). But I insist that from the command line they look ok. Furthermore "fdisk" (from the fonera command line) reports that the sector size is 4096 bytes (quote: "Note: sector size is 4096 (not 512)").

comment:6 Changed 7 years ago by matthijs

I made a bit more progress: It seems that there is some problem in the msdos partition table code, that incorrectly sizes partitions. With a 3TB 4096-byte-sector disk, I get the following:

root@Fonera:/# fdisk -u -l /dev/sda
Disk /dev/sda: 3000.5 GB, 3000592977920 bytes
255 heads, 63 sectors/track, 45600 cylinders, total 732566645 sectors
Units = sectors of 1 * 4096 = 4096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63   732564062  2930256000    7  HPFS/NTFS

root@Fonera:/# cat /proc/partitions
major minor  #blocks  name
   8     0 2930266580 sda
   8     1  782772352 sda1

It seems I can read all of the disk using /dev/sda, but /dev/sda1 breaks earlier (though it seems I can read a bit more than the number of bytes listed in /proc/partitions, not sure what's going on there.

Note that one working system, /proc/partitions matches the fdisk output above:

matthijs@grubby:~$ cat /proc/partitions 
major minor  #blocks  name
   8       16 2930266580 sdb
   8       17 2930256000 sdb1

Furthermore, I found this commit in the upstream kernel git, which fixes the msdos partition table to use 64-bit integers instead of 32-bit.

And, given that 2930256000 % (231) == 782772352 I think we're really seeing this problem here (31 because the sector size is signed).

I'm currently trying to backport these patches to the 2.0n and 2.0g kernels, I'll update here when I know it they work (I'll have to fix some compilation issues first, it seems).

I'll look at GPT separately.

comment:7 Changed 7 years ago by matthijs

What I said about the size being signed is not correct, it was already unsigned. However, the size is stored in sectors, not blocks (block = 1024 bytes, sector=512 bytes). So, internally, 2930256000 blocks is stored as 5860512000 sectors, and 5860512000 % 232 == 1565544704 sectors == 782772352 blocks.

comment:8 Changed 7 years ago by matthijs

Ok, from a first test, it seems the backported kernel patches seem to fix msdos partitions > 2TB :-D

comment:9 Changed 7 years ago by matthijs

I just tried a GPT partition table (on a small disk for now, I need to clear out some data from my big disk before I can change the partition table there) and that seems to work just fine. The partition table is recognized and the partition is mounted correctly.

This "partition table not recognized" error you mentioned, where did you see it? In the dmesg output?

Possibly GPT support is somehow broken for big disks, Looking at the upstream kernel commits, I found this commit, which suggests that GPT partition tables were broken on devices with 4k sectors. I'll see if I can backport that patch as well and free up my big disk for testing this.

comment:10 Changed 7 years ago by matthijs

  • Severity changed from unknown to major
  • Status changed from confirmed to testing-fix
  • Version changed from 2.3.7.0 beta2 to 2.3.7.0 beta3

Ok, backporting that commit works, I now have a single 3TB GPT partition working as well (and I confirmed that this setup is in fact broken in beta3, I got the "partition table not recognized" message).

I'll clean this stuff up (including a bunch of mountd improvements) and then ask people to test their big disks using an svn autobuild.

comment:11 Changed 7 years ago by matthijs

(In [2144]) kernel: Enable GPT / EFI partition table support on 2.0g.

This support was already enabled on 2.0n, but still disabled on 2.0g.

References: #1177

comment:12 Changed 7 years ago by matthijs

  • Resolution set to fixed
  • Status changed from testing-fix to closed

(In [2145]) kernel: Make disks with 4k sectors work.

This backports three patches from newer kernel versions which fix the msdos and GPT (efi) partition table parsing on disks with 4096-byte sectors (i.e., most modern big disks).

This should be the last part in making disks larger than 2TB work with both the 2.0n and the 2.0g.

Closes: #1177

comment:13 Changed 7 years ago by matthijs

(In [2146]) mountd: Fix partition size display for 4k-sector drives.

luci would interpret the size from mountd as a count of logical sectors, but it was really a count of 512-byte sectors. So instead of using the sector size of the disk, just hardcode a sector size of 512.

References: #1177

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.