[LWN Logo]
From:	 Peter Chubb <peter@chubb.wattle.id.au>
To:	 linux-kernel@vger.kernel.org
Subject: [PATCH] remove 2TB block device limit
Date:	 Fri, 10 May 2002 13:36:07 +1000
Cc:	 akpm@zip.com.au, martin@dalecki.de, neilb@cse.unsw.edu.au

	At present, linux is limited to 2TB filesystems even on 64-bit
systems, because there are various places where the block offset on
disc are assigned to unsigned or int 32-bit variables.

There's a type, sector_t, that's meant to hold offsets in sectors and
blocks.  It's not used consistently (yet).

The patch at

(also available from bk://gelato.unsw.edu.au:2023/ for those using
has the following changes to address the problem:

	bmap() changes from int bmap(struct address_space *, long)
	to		    sector_t bmap(struct address_space *,

	The partitioning code takes sector_t everywhere that makes
	sense (to allow efi, for example, to create partitions on enormous

	The block_sizes[] array is sector_t not int.

	get_nr_sectors() and get_start_sect() etc., now return a

	__bread() takes a sector_t as its second argument, and struct
	buffer_head contains a sector_t blocknumber field.

	struct scsi_disk and struct gendisk have a sector_t field for

	The scsi disc code now uses 16-byte commands if they're

	ioctl(..GETBLKSZ..) now fails with EFBIG if the size won't fit
	in a long. (at least for devices using the generic version).

Plus a smattering of casts to avoid compilation warnings (mostly so
that printk() works whether sector_t is 64 or 32 bits) and a new
CONFIG_LFS option to turn on 64-bit sector_t on 32-bit platforms.

On an old pentium I now have a 15Tb file mounted as JFS on the loop
device -- and it seems to work for almost everything.  There are a few
user-mode programs that'll have to be fixed (notably parted, mkfs.???
etc) to cope with the new GETBLKSIZE failure (they should use
alternate mechanisms, e.g., GETBLKSIZE64, or just seek to the end of
the partition and look at the offset).

As this touches lots of places -- the generic block layer (Andrew?)
the IDE code (Martin?) and RAID (Neil?) and minor changes to the scsi
I've CCd a few people directly.

Peter Chubb
Gelato@UNSW http://www.gelato.unsw.edu.au/
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/