lkml.org 
[lkml]   [1998]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: 2G file size limitation question
Date
From
Ted Ts'o writes:
...
> It would require massive restructuring of the virtual memory management
> layer for the i386, since file I/O is done through the page cache, which
> also has the 32 bit limitation.

Yes and no. Well, at least the interfaces that FS modules
get are somewhat mixed:

long long ext2_file_lseek( FILP*, long long offset, int pos )
ssize_t ext2_file_write( FILP*, char *buf, size_t len, loff_t *ppos)
(read thru generic_file_read(), which params looks alike..)

And yet, the code check that it can't write beyond 2^32 bits,
because then it can't write the size into the i-node.
Also the i-node kept in RAM holds i_size as __u32, and
many things trust that, and some write there SIGNED 32-bit
values -- I think the ftruncate() is one. (Sigh..)

IMO, the VMM/VFS layer need to become pure 64-bit, before
we can benefit from having fully 64-bit backends.

Independently of that, I have been toying with my workstation
EXT2 filesystems after I had made enough vague analysis things
about the performance of the EXT2 (and any other indirect block
addressing scheme) with large files.

I will post my writeup about those in separate email.

In every case, I think we have only so much things that we
can do with current EXT2 structure, before we must go to EXT3,
and frankly the 64-bit issue feels more and more of such.
(But my performance increase ideas do work at EXT2, although
you need to have appropriate FS driver and tools, or you will
be blowing your contiguous files...)

> - Ted

/Matti Aarnio <matti.aarnio@tele.fi>

\
 
 \ /
  Last update: 2005-03-22 13:41    [from the cache]
©2003-2011 Jasper Spaans