using 2 TB in real life

I've just added a 1.9 TB array to one of my servers (running 2.4.20, the device is an 12bay-IFT IDE-to-Fibre-RAID connected via a Qlogic 2300 HBA):

Disk /dev/sdb: 255 heads, 63 sectors, 247422 cylinders Units = cylinders of 16065 * 512 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 247422 1987417183+ 83 Linux
[...]
Attached scsi disk sdb at scsi2, channel 0, id 0, lun 0 SCSI device sdb: -320126976 512-byte hdwr sectors (-163904 MB)
sdb: sdb1

Another array (1.2 TB) gives almost the same effect:
Disk /dev/sdb: 255 heads, 63 sectors, 157450 cylinders Units = cylinders of 16065 * 512 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 157450 1264717093+ 83 Linux
[...]
Attached scsi disk sdb at scsi2, channel 0, id 0, lun 0 SCSI device sdb: -1765523456 512-byte hdwr sectors (195564 MB)
sdb: sdb1

These issues arise when using arrays larger than around 0.5 T; nevertheless, these devices do work fine with both xfs or ext3, it's "just" a cosmetical issue. However, this negative values make one feel like Linux isn't truely capable of using up to 2 TB of disk devices and so this should be resolved.
To me it seems that sd.c doesn't know how to calculate the correct values for such beasts - any ideas?

Regards

Anders

http://sysiphus.de/

Looks like it's already handled in 2.5.
Here's a patch for 2.4:
http://www.gelato.unsw.edu.au/patches-index.html

----- Original Message -----
From: "Anders Henke" <[email protected]>
To: <[email protected]>
Sent: Thursday, December 12, 2002 6:12 AM
Subject: using 2 TB in real life

The result of the device size calculation that Anders complained about in 2.4.20 was wrong in a different way in Peter's >2TB patch, last I looked. I don't think Peter's patch is necessary for a 1.9TB device, anyway.

	<b

Peter's patch is not necessary for a 1.9TB device, but (from a quick glance at the source) should fix the display problem I mentioned.

Personally I've no problem using 2.4.20 without this patch applied, although sd.c makes 1.9TB devices look as being something coming from a very dark corner of the universe ...

I knew of the 2 TB limit before, but the strange output brought me to extensively test both xfs and ext3 on it before writing any important data on the device. Other people might assume that Linux simply cannot handle (scsi/fc) devices larger than 0.5 TB or think Linux of being of less quality than $other_operating_system ("they claim 2 TB is the limit, but it somehow chokes at only 0.5 TB").

It would be a very kind thing if someone knows how to fix sd.c that way would do it before such ideas arise - unluckily, I don't have the in-depth knowledge to do this, so I'm sending this as a notice to linux-kernel (as this is the place where I believe the ones are who know how to do fix it).

Regards,

Anders

http://sysiphus.de/

No, my point was precisely that Peter's patch changes the display problem into a different display problem. It will report a 1.9TB filesystem as a 300MB filesystem, because some of the bit-shuffling is wrong.

I've attached a patch which illustrates a fix to the SCSI device size reporting problem in Peter's 2TB patch (the fix was found by HJ Lu). It probably won't apply cleanly due to version drift (and of course it definitely won't apply to a stock kernel), but it indicates what's wrong.

	<b

@@ -1002,8 +1002,8 @@
 			 */
 			int m;
 			unsigned hard_sector = sector_size;
-			sector_t sz = rscsi_disks[i].capacity * (hard_sector/256);
-			sector_t mb = sz >>= 1;
+			sector_t sz = ((sector_t) rscsi_disks[i].capacity) * ((sector_t) (hard_sector/256));
+			sector_t mb = sz >> 1;
 			sector_div(sz, 1250);
 			mb -= sz - 974;
 			

@@ -1015,9 +1015,9 @@
 			}
 
 			printk("SCSI device %s: "
-			       "%u %u-byte hdwr sectors (%u MB)\n",
+			       "%u %u-byte hdwr sectors (%llu MB)\n",
 			       nbuff, rscsi_disks[i].capacity,
-			       hard_sector, sz);
+			       hard_sector, mb);
 		}
 
 		/* Rescale capacity to 512-byte units */