Messages in this thread | | | Date | Sat, 20 Mar 1999 18:43:13 +0100 (CET) | From | Andrea Arcangeli <> | Subject | breaking 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/
| |