lkml.org 
[lkml]   [1999]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectbreaking the 2Gigabyte limit on 32 bit arch of inode->i_size (off_t vs loff_t)
    Which is the best way to handle inode sizes > 2gigabyte on 32bit archs?

    I just seen that llseek and all file->f_pos offset uses long long
    (loff_t). So it looks like to me that instead of use a separate
    i_size_high in the inode_info struct (as we now do to avoid to write on
    inode that are just bigger than 2giga), I could more simply declare
    inode->i_size as loff_t (64bit) instead of off_t (as it is now).

    What about gcc bugs with long long types? But if gcc just deal with the
    loff_t of lseek and file->f_pos why shouldn't work with some more bits of
    loff_t ;)?

    My point for doing this is that in the near future we'll _finally_ run on
    64bit and so long long will just be an alias of long, so no performance
    penalities even if only using small offset... And in the meantime we'll be
    able to handle >2gigabyte files on 32bit archs (going always a bit slower
    of course, but as just said it would be only a _temporary_ slowdown).

    Once the i_size will be long long the new limits will be the number of
    blocks we'll be able to address via the inode block table.

    I did a little count:

    - 256 block indexed in a blocksize of 1k
    - 12 direct block
    - 1 indirect, 1 double-indirect, 1 triple-indirect

    so the number of blocks we'll be able to address once we'll broke the
    i_size limit will be:

    12 + 256 + 256^2 + 256^3 -> 16843020

    Considering blocksize = 1k we'll be able to address only 16giga according
    to me. So I'll add a quad level of indirection. This will give as a view
    of 4000gigabyte per file. Is this a rasonable limit or my mind is looking
    too much in the short term? And btw if we'll have a 4000gigabyte hd I bet
    we'll also have blocksizes a bit larger than 1k. Hmm.

    Then there is the issue of the number of blocks handled by the buffer.c
    code. Right now the number of blocks is a _signed_ int (so 31bit also on
    64bit arch if I interpreted well what I read in the past on the list in
    some random email). And all reference to blocks are saved on __u32 on
    disk.

    2giga of blocks will give us an high limit of 2*1024giga = 2048gigabyte.
    So we won't able to address a blockdevice with more than 2000gigabyte if
    the blocksize is 1k. So I'll make the blocknumber a __u64 on the physical
    HD layer, and a long (not long long) in memory to allow at least 64bit
    arch to break this limit and so allow infinity ;) block device sizes.

    Comments?

    Andrea Arcangeli


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:50    [W:0.021 / U:0.916 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site