Hi folks,
there's a new version of the large block device patch at
http://www.gelato.unsw.edu.au/patches/2.5.24-lbd-patch
Barring errors, this patch allows use of arbitrarily sized devices on
64 bit platforms, and, with a configuration option, allows up to 16Tb
devices on 32bit platforms.
The bulk of the patch is fixing the various SCSI driver's magic to
convert a size to a CHS.
The important bits are:
-- disc sizes kept as sector_t not int
-- struct request takes a sector_t not a long as the block number
to transfer
-- sector_t is defined as unsigned long for most platforms; as u64
iff CONFIG_LBD is defined
-- the BLKGETSIZE iotcl returns EFBIG if the size cannot be
represented in a long (maybe that should be EOVERFLOW same as
lseek?)
-- loop device transfer functions now in terms of sector_t
-- loop device refuses to attach to a file or device that is too
large (instead of silently failing)
-- casts to unsigned long long and appropriate printf formats
where sector offsets are given to printk()
-- New macro sector_div (based on div64()) to do (possibly 64-bit)
division and remainder where it's necessary (only for printing
the size of a partition converted to MB)
-- Modifications to the scsi disc handler to use 16-byte commands
iff the blocknumber is out-of-range for a 10-byte command.
Courtesy of OSDL, I'm currently testing this patch on ia64 and ia32.
If other people with enormous discs could test it too, and tell me
what they find, that'd be extremely helpful.
You may need fixed versions of the various filesystem tools, too.
JFSutils 1.0.20 has been fixed, I believe; if you need instead a
patched 1.0.19 you can fetch it from http://gelato.unsw.edu.au/debian
Likewise, there is a patched e2fsprogs and reiserfsprogs there.
--
Dr Peter Chubb [email protected]
You are lost in a maze of BitKeeper repositories, all almost the same.
>>>>> "Amit" == Amit Agrawal <Amit> writes:
Amit> Hi Peter I think some places in files 'pagemap.h' and
Amit> 'filemap.c' still uses unsigned long instead of sector_t,these
Amit> files are not touched by your patch, please see to it........
The `index' in pagemap.h and filemap.c is an index into the pagecache,
not a disk offset --- so it stays as unsigned long. I think there are
plans to change it to `pgoff_t', or to change the size of an object in
the pagecacheat some stage, but for now the
pagecache on a 32-bit architecture is limited to addressing
((2^32)-1) * PAGECACHE_SIZE, which makes a limit of 16TB on 32-bit
architectures at present.
--
Dr Peter Chubb [email protected]
You are lost in a maze of BitKeeper repositories, all almost the same.