The specific problem is that if a partition or device is larger than 4GB,
certain block reads to the /dev/sd<x> or /dev/sd<x><n> device may fail, even
though there is nothing wrong with the media. I discovered this while running
the badblocks program on a new IBM Ultrastar XP 4.5GB drive (4303 cylinders).
It declared a particular block bad for no apparent reason, and even though the
drive should have remapped all the bad blocks. After tracing through my
BusLogic SCSI driver trying to figure out why no error messages were logged,
and finding out that it was never even called, I tracked the problem to
"fs/block_dev.c":
--- linux/fs/block_dev.c- Mon Jan 23 13:04:09 1995
+++ linux/fs/block_dev.c Mon Jul 31 14:30:09 1995
@@ -197,6 +197,9 @@
if (offset > size)
left = 0;
+ /* size - offset might not fit into left, so check explicitly. */
+ else if (size - offset > INT_MAX)
+ left = INT_MAX;
else
left = size - offset;
if (left > count)
What happens is that SIZE and OFFSET are both loff_t (long long), so the
calculation of the unsigned int LEFT can incorrectly become 0 when OFFSET and
SIZE are equal modulo 4GB. I chose the simple patch above rather than changing
LEFT to loff_t, since it seems more conservative in this case.
I don't recall if there are any outstanding problems with large drives that
haven't been explained by people having old versions of fdisk and e2fsprogs,
but if there are, this fix might take care of them.
Leonard