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    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site