[lkml]   [1998]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2G file size limitation question
    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 <>

     \ /
      Last update: 2005-03-22 13:41    [W:0.019 / U:3.168 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site