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
> 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/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Thu, 2002-12-12 at 04:03, Mike Black wrote:
> 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
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
On Dec 12th 2002, Bryan O'Sullivan wrote:
> On Thu, 2002-12-12 at 04:03, Mike Black wrote:
> > 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
>
> 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.
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/
On Thu, 2002-12-12 at 09:48, Anders Henke wrote:
> 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.
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
> SCSI device sdb: -320126976 512-byte hdwr sectors (-163904 MB)
Yes, the code in 2.4.20 works up to 30 bits.
A slight modification works up to 31 bits.
[This is cosmetic only.]
Andries
--- /linux/2.4/linux-2.4.20/linux/drivers/scsi/sd.c Sat Aug 3 02:39:44 2002
+++ ./sd.c Fri Dec 13 00:12:00 2002
@@ -1001,7 +1001,7 @@
*/
int m;
int hard_sector = sector_size;
- int sz = rscsi_disks[i].capacity * (hard_sector/256);
+ unsigned int sz = (rscsi_disks[i].capacity/2) * (hard_sector/256);
/* There are 16 minors allocated for each major device */
for (m = i << 4; m < ((i + 1) << 4); m++) {
@@ -1009,9 +1009,9 @@
}
printk("SCSI device %s: "
- "%d %d-byte hdwr sectors (%d MB)\n",
+ "%u %d-byte hdwr sectors (%d MB)\n",
nbuff, rscsi_disks[i].capacity,
- hard_sector, (sz/2 - sz/1250 + 974)/1950);
+ hard_sector, (sz - sz/625 + 974)/1950);
}
/* Rescale capacity to 512-byte units */
On December 13th 2002, [email protected] wrote:
> > SCSI device sdb: -320126976 512-byte hdwr sectors (-163904 MB)
>
> Yes, the code in 2.4.20 works up to 30 bits.
> A slight modification works up to 31 bits.
It works up to less than 30 bits - a 0.9 TB Device shows up as
SCSI device sdb: 1806745600 512-byte hdwr sectors (-174457 MB)
while a 480 GB Device (correctly) shows up this way:
SCSI device sda: 961818624 512-byte hdwr sectors (492451 MB)
At 0.5 TB (29 bits) the first problem occurs: negative size.
At 1 T (30 bits), the sector count also becomes negative.
Your patch (thank you!) does fix both problems and up to 1.9 TB,
everything works as expected:
SCSI device sdb: 3974840320 512-byte hdwr sectors (2035118 MB)
Yes, it's purely cosmetical, but should be included in the main tree.
Regards,
Anders
--
http://sysiphus.de