Messages in this thread | | | Subject | Re: 2G file size limitation question | Date | Fri, 9 Jan 1998 18:03:28 +0000 (/etc/localtime) | From | Matti Aarnio <> |
| |
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>
| |