[PATCH] remove 2TB block device limit
Neil Brown
>
> Hi,
> 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
> http://www.gelato.unsw.edu.au/patches/2.5.14-largefile-patch
>
> 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.
>
Thanks.
MD part looks sane to me. However I would rather the
+#ifdef CONFIG_LFS
+#include <asm/div64.h>
+#else
+#undef do_div
+#define do_div(n, b)({ int _res; _res = (n) % (b); (n) /= (b); _res;})
+#endif
+
part went in linux/raid/md_k.h and defined "sector_div" (or similar)
as either do_div or ({ int _res; _res = (n) % (b); (n) /= (b); _res;})
as appropriate.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
>
> Hi,
> 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
> http://www.gelato.unsw.edu.au/patches/2.5.14-largefile-patch
>
>
> 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.
That would be more Jens and aviro than I.
My vote would be: just merge the sucker while it still (almost)
applies. 2TB is a showstopper for some people in 2.4 today. Obviously
2.6 will need 64-bit block numbers.
The next obstacle will be page cache indices into the blockdev mapping.
That's either an 8TB or 16TB limit, depending on signedness correctness.
One minor point - it is currently not possible to print sector_t's.
This code:
printk("%lu%s", some_sector, some_string);
will work fine with 32-bit sector_t. But with 64-bit sector_t it
will generate a warning at compile-time and an oops at runtime.
The same problem applies to dma_addr_t. Jeff, davem and I kicked
that around a while back and ended up deciding that although there
are a number of high-tech solutions, the dumb one was best:
--- 2.5.14/include/linux/types.h~sector_t-printing Thu May 9 17:08:13 2002
+++ 2.5.14-akpm/include/linux/types.h Thu May 9 17:08:13 2002
@@ -120,8 +120,10 @@ typedef __s64 int64_t;
#ifdef BLK_64BIT_SECTOR
typedef u64 sector_t;
+#define FMT_SECTOR_T "%Lu"
#else
typedef unsigned long sector_t;
+#define FMT_SECTOR_T "%lu"
#endif
#endif /* __KERNEL_STRICT_NAMES */
--- 2.5.14/fs/buffer.c~sector_t-printing Thu May 9 17:08:13 2002
+++ 2.5.14-akpm/fs/buffer.c Thu May 9 17:09:35 2002
@@ -179,7 +179,8 @@ __clear_page_buffers(struct page *page)
static void buffer_io_error(struct buffer_head *bh)
{
- printk(KERN_ERR "Buffer I/O error on device %s, logical block %ld\n",
+ printk(KERN_ERR "Buffer I/O error on device %s,"
+ " logical block " FMT_SECTOR_T "\n",
bdevname(bh->b_bdev), bh->b_blocknr);
Peter Chubb
Hi,
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).
(also available from bk://gelato.unsw.edu.au:2023/ for those using
bitkeeper)
has the following changes to address the problem:
bmap() changes from int bmap(struct address_space *, long)
to sector_t bmap(struct address_space *,
sector_t)
The partitioning code takes sector_t everywhere that makes
sense (to allow efi, for example, to create partitions on enormous
discs).
The block_sizes[] array is sector_t not int.
get_nr_sectors() and get_start_sect() etc., now return a
sector_t
__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
capacity.
The scsi disc code now uses 16-byte commands if they're
needed.
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/
Martin Dalecki
> Hi,
> 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 IDE part of it appears to be sane. I will take it.
Jens Axboe
> Why not the even dumber one? Forget FMT_SECTOR_T and always use %Lu and
> typecast (unsigned long long)sector_t_variable in the printk.
I like that better too, it's what I did in the block layer too.
--
Jens Axboe
Andrew Morton
>
> ...
> >This code:
> >
> > printk("%lu%s", some_sector, some_string);
> >
> >will work fine with 32-bit sector_t. But with 64-bit sector_t it
> >will generate a warning at compile-time and an oops at runtime.
> >
> >The same problem applies to dma_addr_t. Jeff, davem and I kicked
> >that around a while back and ended up deciding that although there
> >are a number of high-tech solutions, the dumb one was best:
>
> typecast (unsigned long long)sector_t_variable in the printk.
>
Agree. The nice thing about the typecast is that you
can format the output with %06Lx, %9Ld, %Lo or whatever.
The FMT_SECTOR_T thing forces you to use the chosen formatting.
-
Anton Altaparmakov
>Peter Chubb wrote:
> >
> > Hi,
> > 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 IDE code (Martin?) and RAID (Neil?) and minor changes to the scsi
> > I've CCd a few people directly.
>
>
>My vote would be: just merge the sucker while it still (almost)
>applies. 2TB is a showstopper for some people in 2.4 today. Obviously
>2.6 will need 64-bit block numbers.
>
>The next obstacle will be page cache indices into the blockdev mapping.
>That's either an 8TB or 16TB limit, depending on signedness correctness.
>
>One minor point - it is currently not possible to print sector_t's.
>
> printk("%lu%s", some_sector, some_string);
>
>will work fine with 32-bit sector_t. But with 64-bit sector_t it
>will generate a warning at compile-time and an oops at runtime.
>
>The same problem applies to dma_addr_t. Jeff, davem and I kicked
>that around a while back and ended up deciding that although there
>are a number of high-tech solutions, the dumb one was best:
Why not the even dumber one? Forget FMT_SECTOR_T and always use %Lu and
typecast (unsigned long long)sector_t_variable in the printk.
May be ugly, but isn't it correct that you actually need the above typecast
on some architectures where %Lu == unsigned long long != u64?
Anton
>--- 2.5.14/include/linux/types.h~sector_t-printing Thu May 9
>17:08:13 2002
>+++ 2.5.14-akpm/include/linux/types.h Thu May 9 17:08:13 2002
>@@ -120,8 +120,10 @@ typedef __s64 int64_t;
>
> #ifdef BLK_64BIT_SECTOR
> typedef u64 sector_t;
>+#define FMT_SECTOR_T "%Lu"
> #else
> typedef unsigned long sector_t;
>+#define FMT_SECTOR_T "%lu"
> #endif
>
> #endif /* __KERNEL_STRICT_NAMES */
>--- 2.5.14/fs/buffer.c~sector_t-printing Thu May 9 17:08:13 2002
>+++ 2.5.14-akpm/fs/buffer.c Thu May 9 17:09:35 2002
>@@ -179,7 +179,8 @@ __clear_page_buffers(struct page *page)
>
> static void buffer_io_error(struct buffer_head *bh)
> {
>- printk(KERN_ERR "Buffer I/O error on device %s, logical block %ld\n",
>+ printk(KERN_ERR "Buffer I/O error on device %s,"
>+ " logical block " FMT_SECTOR_T "\n",
> bdevname(bh->b_bdev), bh->b_blocknr);
> }
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majo...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
Peter Chubb
Jens> On Fri, May 10 2002, Anton Altaparmakov wrote:
>> Why not the even dumber one? Forget FMT_SECTOR_T and always use %Lu
>> and typecast (unsigned long long)sector_t_variable in the printk.
Jens> I like that better too, it's what I did in the block layer too.
That's exactly what I did in the patch....
Except most places I used u64 not unsigned long long (it's the same
thing on all architectures, and much shorter to type).
Peter C
Jens Axboe
> >>>>> "Jens" == Jens Axboe <ax...@suse.de> writes:
>
> Jens> On Fri, May 10 2002, Anton Altaparmakov wrote:
> >> Why not the even dumber one? Forget FMT_SECTOR_T and always use %Lu
> >> and typecast (unsigned long long)sector_t_variable in the printk.
>
> Jens> I like that better too, it's what I did in the block layer too.
>
> That's exactly what I did in the patch....
Excellent
> Except most places I used u64 not unsigned long long (it's the same
> thing on all architectures, and much shorter to type).
Patch looks fine to me. I was hoping someone would do the grunt
conversion work when I introduced sector_t, thanks! :-)
--
Jens Axboe
Anton Altaparmakov
> >>>>> "Jens" == Jens Axboe <ax...@suse.de> writes:
>
>Jens> On Fri, May 10 2002, Anton Altaparmakov wrote:
> >> Why not the even dumber one? Forget FMT_SECTOR_T and always use %Lu
> >> and typecast (unsigned long long)sector_t_variable in the printk.
>
>Jens> I like that better too, it's what I did in the block layer too.
>
>That's exactly what I did in the patch....
>
>thing on all architectures, and much shorter to type).
I have been told that this is wrong (it was on this list but I can't
remember who said it - it was one of the prominent kernel hackers... (-;).
u64 is not necesssarily unsigned long long type and this causes compilation
problems on some architectures (apparently).
Anton
>Peter C
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majo...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
-
Peter Chubb
Jeremy> Peter, Out of curiousity, what then does the new filesystem
Jeremy> limit become, on a 64-bit system? Will all filesystems
Jeremy> support your changes?
This depends on the file system.
See
http://www.gelato.unsw.edu.au/~peterc/lfs.html
(which I'm intending to update next week, after some testing to
check the new limits with my new code -- I found the 1TB limit in
the generic code (someone using a signed int instead of unsigned long))
There are three different limits that apply:
--- The physical layout on disc (e.g., ext2 uses 32-bit for block
numbers within a file system; thus the max size is
(2^32-1)*block_size; although it's theoretically possible to use
larger blocksizes, the current toolchain has a maximum of 4k,
thus the largest size of an ext[23] filesystem is ((2^32)-1)*4k
bytes --- around 16TB)
It's extremely unlikely that you'd want to use a non-journalled
file system on such a large partition, so your best bets are
reiserfs, jfs or XFS. jfs and xfs work well on enormous
partitions on other platforms; the current version of reiserfs is
somewhat limited, but version 4 will allow larger file systems.
--- Limitations imposed by the partitioning scheme.
As far as I know, only the EFI GUID partitioning scheme uses
64-bit block offsets, so under any other scheme you're limited to
2^32 or 2^31 blocks per disc; some use the underlying hardware
sector size, some use a block size that's multiple of this.
--- The page cache limit (which on a 32-bit system is 16TB; on a 64
bit system is 18 EB
Jeremy> Mind if I quote what you say on my webpage?
Go ahead
--
Peter Chubb
pet...@gelato.unsw.edu.au http://www.gelato.unsw.edu.au
Andreas Dilger
> See http://www.gelato.unsw.edu.au/~peterc/lfs.html
> (which I'm intending to update next week, after some testing to
> check the new limits with my new code -- I found the 1TB limit in
> the generic code (someone using a signed int instead of unsigned long))
Any chance you could rename this from "LFS" to something else (e.g. LBD
for Large Block Device). LFS == Large File Summit which describes the
use/access of > 2GB _files_ on 32-bit systems under Unix.
> There are three different limits that apply:
>
> --- The physical layout on disc (e.g., ext2 uses 32-bit for block
> numbers within a file system; thus the max size is
> (2^32-1)*block_size; although it's theoretically possible to use
> larger blocksizes, the current toolchain has a maximum of 4k,
> thus the largest size of an ext[23] filesystem is ((2^32)-1)*4k
> bytes --- around 16TB)
For 64-bit systems like Alpha, it is relatively easy to use 8kB blocks for
ext3. It has been discouraged because such a filesystem is non-portable
to other (smaller page-sized) filesystems. Maybe this rationale should
be re-examined - I could probably whip up a configure option for
e2fsprogs to allow 8kB blocks in a few hours.
Does x86-64 and/or ia64 actually _use_ > 4kB page sizes? If so, it
may be more worthwhile to allow larger block sizes with e2fsprogs.
It may be that the kernel supports >4kB blocks already on systems with
larger PAGE_SIZE, I don't know (no way for me to test this).
> It's extremely unlikely that you'd want to use a non-journalled
> file system on such a large partition, so your best bets are
> reiserfs, jfs or XFS.
I find it somewhat ironic that you suggest reiserfs over ext3, when in
fact they both currently have the same 16TB filesystem limit. On your
web page, you say the ext[23] limit is 1TB, which it definitely is not
(unless there are bugs in the code). There is currently a 16TB filesystem
limit for 4kB blocks, but there are plans towards fixing that also.
> --- Limitations imposed by the partitioning scheme.
> As far as I know, only the EFI GUID partitioning scheme uses
> 64-bit block offsets, so under any other scheme you're limited to
> 2^32 or 2^31 blocks per disc; some use the underlying hardware
> sector size, some use a block size that's multiple of this.
LVM does not need to have partitions, and presumably EVMS using Linux
or AIX LVM devices doesn't either.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
David Mosberger
Andreas> For 64-bit systems like Alpha, it is relatively easy to use
Andreas> 8kB blocks for ext3. It has been discouraged because such
Andreas> a filesystem is non-portable to other (smaller page-sized)
Andreas> filesystems. Maybe this rationale should be re-examined -
Andreas> I could probably whip up a configure option for e2fsprogs
Andreas> to allow 8kB blocks in a few hours.
If you do this, please consider allowing a block size up to 64KB.
The ia64 kernel offers a choice of 4, 8, 16, and 64KB page size.
Andreas> Does x86-64 and/or ia64 actually _use_ > 4kB page sizes?
ia64 linux normally uses > 4KB. The recommended page size at the
moment is 16KB. I didn't think 64KB would become realistic for quite
some time, but performance is surprisingly good, even on today's
systems.
--david
Peter Chubb
Andreas> On May 11, 2002 05:12 +1000, Peter Chubb wrote:
>> See http://www.gelato.unsw.edu.au/~peterc/lfs.html (which I'm
>> intending to update next week, after some testing to check the new
>> limits with my new code -- I found the 1TB limit in the generic
>> code (someone using a signed int instead of unsigned long))
Andreas> Any chance you could rename this from "LFS" to something else
Andreas> (e.g. LBD for Large Block Device). LFS == Large File Summit
Andreas> which describes the use/access of > 2GB _files_ on 32-bit
Andreas> systems under Unix.
Will do.
Andreas> Does x86-64 and/or ia64 actually _use_ > 4kB page sizes? If
Andreas> so, it may be more worthwhile to allow larger block sizes
Andreas> with e2fsprogs. It may be that the kernel supports >4kB
Andreas> blocks already on systems with larger PAGE_SIZE, I don't know
Andreas> (no way for me to test this).
ia64 uses 16k standard; you can choose up to 64k and get performance
gains.
The main limitation on performance on a modern architecture is the
limited TLB coverage of the large real address space --- large pages
give fewer TLB entries for the same coverage, which leads to better
performance.
>> It's extremely unlikely that you'd want to use a non-journalled
>> file system on such a large partition, so your best bets are
>> reiserfs, jfs or XFS.
Andreas> I find it somewhat ironic that you suggest reiserfs over
Andreas> ext3, when in fact they both currently have the same 16TB
Andreas> filesystem limit. On your web page, you say the ext[23]
Andreas> limit is 1TB, which it definitely is not (unless there are
Andreas> bugs in the code). There is currently a 16TB filesystem
Andreas> limit for 4kB blocks, but there are plans towards fixing that
Andreas> also.
I found the limitation --- it was in the block layer, not ext2.
There were bugs in the other FS that let me create files bigger than
the 2TB pagecache limit, even though when I tried to write them bad
things happened.
Updating that web page is on my TODO list for Monday...
>> --- Limitations imposed by the partitioning scheme. As far as I
>> know, only the EFI GUID partitioning scheme uses 64-bit block
>> offsets, so under any other scheme you're limited to 2^32 or 2^31
>> blocks per disc; some use the underlying hardware sector size, some
>> use a block size that's multiple of this.
Andreas> LVM does not need to have partitions, and presumably EVMS
Andreas> using Linux or AIX LVM devices doesn't either.
Sure. Discs and hardware raids don't need partitions either, providing the
size of the media is smaller than the filesystem-layout-imposed size limit.
The reasons, as far as I'm concerned, for partitioning a disc are:
-- convenience, to allow controlled sharing of discs
-- to allow striping of swap space across multiple spindles (have
a swap partition on each drive)
-- to keep filesystem size below backup-medium size.
If you want to boot from a drive, it'd better have a volume header
that the firmware (e.g., the BIOS) understands, too.
Padraig Brady
http://www.cs.uml.edu/~acahalan/linux/ext2.gif
I just might get around to updating/expanding it.
Padraig.
Peter Chubb wrote:
>>>>>>"Jeremy" == Jeremy Andrews <jer...@kerneltrap.org> writes:
>>>>>
>
> Jeremy> Peter, Out of curiousity, what then does the new filesystem
> Jeremy> limit become, on a 64-bit system? Will all filesystems
> Jeremy> support your changes?
>
> This depends on the file system.
> See
> http://www.gelato.unsw.edu.au/~peterc/lfs.html
> (which I'm intending to update next week, after some testing to
> check the new limits with my new code -- I found the 1TB limit in
> the generic code (someone using a signed int instead of unsigned long))
>
> There are three different limits that apply:
>
> --- The physical layout on disc (e.g., ext2 uses 32-bit for block
> numbers within a file system; thus the max size is
> (2^32-1)*block_size; although it's theoretically possible to use
> larger blocksizes, the current toolchain has a maximum of 4k,
> thus the largest size of an ext[23] filesystem is ((2^32)-1)*4k
> bytes --- around 16TB)
>
> It's extremely unlikely that you'd want to use a non-journalled
> file system on such a large partition, so your best bets are
> reiserfs, jfs or XFS. jfs and xfs work well on enormous
> partitions on other platforms; the current version of reiserfs is
> somewhat limited, but version 4 will allow larger file systems.
>
>
> --- Limitations imposed by the partitioning scheme.
> As far as I know, only the EFI GUID partitioning scheme uses
> 64-bit block offsets, so under any other scheme you're limited to
> 2^32 or 2^31 blocks per disc; some use the underlying hardware
> sector size, some use a block size that's multiple of this.
>
> --- The page cache limit (which on a 32-bit system is 16TB; on a 64
> bit system is 18 EB
>
>
> Jeremy> Mind if I quote what you say on my webpage?
>
> Go ahead
>
> --
Peter Chubb
There's now a patch available against 2.5.15, and the BK repository
has been updated to v2.5.15 as well:
http://www.gelato.unsw.edu.au/patches/2.5.15-largefile-patch
bk://gelato.unsw.edu.au:2023/
Peter C
pet...@gelato.unsw.edu.au
Christoph Hellwig
>
> There's now a patch available against 2.5.15, and the BK repository
> has been updated to v2.5.15 as well:
>
> http://www.gelato.unsw.edu.au/patches/2.5.15-largefile-patch
> bk://gelato.unsw.edu.au:2023/
This looks really good, I'd like to see something like that merged soon!
Some comments:
- please move the sector_t typedef from <linux/types.h> to <asm/types.h>,
so 64 bit arches don't have to have the CONFIG_ option at all, some
32bit plattforms that are unlikely to ever support large disks
(m68k comes to mind) can make it 32bit unconditionally and some like
i386 can use a config option.
- sector_div should move to a common header (blkdev.h?)
And something related to general sector_t usage:
- what about sector_t vs daddr_t? Linux still has daddr_t, but it is
still always 32bit, I think a big s/sector_t/daddr_t/ would fit the
traditional unix way of doing disk addressing
- why is the get_block block argument a sector_t? It presents a logical
filesystem block which usually is larger than the sector, not to
mention that for the usual blocksize == PAGE_SIZE case a ulong is
enough as that is the same size the pagecache limit triggers.
Peter Chubb
Christoph> On Mon, May 13, 2002 at 08:28:30PM +1000, Peter Chubb
Christoph> wrote:
>> There's now a patch available against 2.5.15, and the BK repository
>> has been updated to v2.5.15 as well:
>>
>> http://www.gelato.unsw.edu.au/patches/2.5.15-largefile-patch
>> bk://gelato.unsw.edu.au:2023/
Christoph> This looks really good, I'd like to see something like that
Christoph> merged soon! Some comments:
Christoph> - please move the sector_t typedef from <linux/types.h> to
Christoph> <asm/types.h>, so 64 bit arches don't have to have the
Christoph> CONFIG_ option at all, some 32bit plattforms that are
Christoph> unlikely to ever support large disks (m68k comes to mind)
Christoph> can make it 32bit unconditionally and some like i386 can
Christoph> use a config option. - sector_div should move to a common
Christoph> header (blkdev.h?)
That's not a bad idea, I'll do it.
Christoph> And something related to general sector_t usage:
Christoph> - what about sector_t vs daddr_t? Linux still has
Christoph> daddr_t, but it is still always 32bit, I think a big
Christoph> s/sector_t/daddr_t/ would fit the traditional unix way of
Christoph> doing disk addressing
Yes I considered that, but daddr_t is exported to userland by the tape
ioctls, and is defined to be 32-bit, so it'd require out-of-kernel changes.
Besides, Jens had introduced sector_t for the purpose of counting
blocks and sectors, so I thought I may as well use it. One could
argue that it's misnamed (personally, I liked Ben's `blkoff_t' for
offset in blocks), but it's been thare for four months or so, and was
already being used in likely places throughout the block layer. I
just extended its use to all the places I thought were necessary
(there may be some paths that I've missed; but I hope not).
Christoph> - why is the get_block block argument
Christoph> a sector_t? It presents a logical filesystem block which
Christoph> usually is larger than the sector, not to mention that for
Christoph> the usual blocksize == PAGE_SIZE case a ulong is enough as
Christoph> that is the same size the pagecache limit triggers.
For filesystems that *can* handle logical filesystem blocks beyond the
2^32 limit (i.e., that use >32bit offsets in their on-disc format),
the get_block() argument has to be > 32bits long. At the moment
that's only JFS and XFS, but reiserfs version 4 looks as if it might
go that way. We'll need this especially when the pagecache limit is
gone.
Besides, blocksize is not usually pagesize. ext[23] uses 1k or 4k
blocks depending on the size and expected use of the filesystem; alpha
pagesize is usually 8k, for example. The arm uses 4k, 16k or 32k
pagesizes depending on the model.
So on 32-bit systems, ulong is not enough. (in fact if you look at
jfs, the first thing jfs_get_block does is convert the block number
arg to a 64-bit number).
Peter C
Anton Altaparmakov
> >>>>> "Christoph" == Christoph Hellwig <h...@infradead.org> writes:
>
> Christoph> On Mon, May 13, 2002 at 08:28:30PM +1000, Peter Chubb
> Christoph> wrote:
> >> There's now a patch available against 2.5.15, and the BK repository
> >> has been updated to v2.5.15 as well:
> >>
> >> http://www.gelato.unsw.edu.au/patches/2.5.15-largefile-patch
> >> bk://gelato.unsw.edu.au:2023/
>
> Christoph> This looks really good, I'd like to see something like that
> Christoph> merged soon! Some comments:
> Christoph> - why is the get_block block argument
> Christoph> a sector_t? It presents a logical filesystem block which
> Christoph> usually is larger than the sector, not to mention that for
> Christoph> the usual blocksize == PAGE_SIZE case a ulong is enough as
> Christoph> that is the same size the pagecache limit triggers.
>
> For filesystems that *can* handle logical filesystem blocks beyond the
> 2^32 limit (i.e., that use >32bit offsets in their on-disc format),
> the get_block() argument has to be > 32bits long. At the moment
> that's only JFS and XFS, but reiserfs version 4 looks as if it might
> go that way. We'll need this especially when the pagecache limit is
> gone.
NTFS uses signed 64 bits for all offsets on disk, too. And yes at the
moment the pagecache limit is also a problem which we just ignore in the
hope that the kernel will have gone to 64 bits by the time devices grow
that large as to start using > 32 bits of blocks/pages...
> Besides, blocksize is not usually pagesize. ext[23] uses 1k or 4k
> blocks depending on the size and expected use of the filesystem; alpha
> pagesize is usually 8k, for example. The arm uses 4k, 16k or 32k
> pagesizes depending on the model.
>
> So on 32-bit systems, ulong is not enough. (in fact if you look at
> jfs, the first thing jfs_get_block does is convert the block number
> arg to a 64-bit number).
NTFS does that, too, but not quite immediately... (-;
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS maintainer / IRC: #ntfs on irc.openprojects.net
-
Andrew Morton
>
> ...
> Christoph> - why is the get_block block argument
> Christoph> a sector_t? It presents a logical filesystem block which
> Christoph> usually is larger than the sector, not to mention that for
> Christoph> the usual blocksize == PAGE_SIZE case a ulong is enough as
> Christoph> that is the same size the pagecache limit triggers.
>
> For filesystems that *can* handle logical filesystem blocks beyond the
> 2^32 limit (i.e., that use >32bit offsets in their on-disc format),
> the get_block() argument has to be > 32bits long. At the moment
> that's only JFS and XFS, but reiserfs version 4 looks as if it might
> go that way. We'll need this especially when the pagecache limit is
> gone.
I think Christoph's point is that a pagecache index is not a sector
number. We agree that we need to plan for taking it to 64 bits, but
it should be something different. Like pageindex_t, or whatever.
This:
--- linux-2.5.15/include/linux/mm.h Tue Apr 30 17:56:30 2002
+++ 25/include/linux/mm.h Mon May 13 19:08:21 2002
@@ -148,7 +148,7 @@ struct vm_operations_struct {
typedef struct page {
struct list_head list; /* ->mapping has some page lists. */
struct address_space *mapping; /* The inode (or ...) we belong to. */
- unsigned long index; /* Our offset within mapping. */
+ sector_t index; /* Our offset within mapping. */
atomic_t count; /* Usage count, see below. */
unsigned long flags; /* atomic flags, some possibly
updated asynchronously */
looks rather silly, no?
-
Peter Chubb
Andrew> Peter Chubb wrote:
>> ...
Christoph> - why is the get_block block argument a sector_t? It
Christoph> presents a logical filesystem block which usually is larger
Christoph> than the sector, not to mention that for the usual
Christoph> blocksize == PAGE_SIZE case a ulong is enough as that is
Christoph> the same size the pagecache limit triggers.
>> For filesystems that *can* handle logical filesystem blocks beyond
>> the 2^32 limit (i.e., that use >32bit offsets in their on-disc
>> format), the get_block() argument has to be > 32bits long. At the
>> moment that's only JFS and XFS, but reiserfs version 4 looks as if
>> it might go that way. We'll need this especially when the
>> pagecache limit is gone.
Andrew> I think Christoph's point is that a pagecache index is not a
Andrew> sector number. We agree that we need to plan for taking it to
Andrew> 64 bits, but it should be something different. Like
Andrew> pageindex_t, or whatever.
I'll let Christoph speak for himself, but my point is that
get_block() is an interface exported from the filesystem. It should
be possible to specify any logical block number that the filesystem
supports. That the current VM system on 32-bit machines will never
request a block beyond 2^32 is a (one-day-soon-to-be-removed) current
limitation.
Peter C
Christoph Hellwig
>
> I think Christoph's point is that a pagecache index is not a sector
> number. We agree that we need to plan for taking it to 64 bits, but
> it should be something different. Like pageindex_t, or whatever.
I don't think we want to increase it. First it grow struct page by 32bits
and second 64bit arithmetic on 32bit plattforms is still very expensive.
I'd rather see PAGE_CACHE_SIZE growing to address the issues.
Christoph Hellwig
> I'll let Christoph speak for himself, but my point is that
> get_block() is an interface exported from the filesystem.
It itsn't. get_block is a callback for the generic block-based filesystem
library routines.