[lkml]   [1998]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: VFS 64-bit clean
Chip Salzenberg writes:
> According to Rik van Riel:
>> On Tue, 17 Feb 1998, Albert D. Cahalan wrote:

>>> __u32 i_blocks; /* Blocks count */
>> The number of blocks needs to be higher when we have
>> 64-bit sized files.
> Good point.
>>> union {
>>> __u32 i_dir_acl; /* Directory ACL (directories only) */
>>> __u32 i_size_high; /* high 32 bits of 64-bit size */
>>> } u2;
>> Looks good.
> Considering the block problem, what about using 24 of those bits for
> extending file size and eight for extending block count? Then you
> have 58-bit size and 36-bit blocks, which is just right for 4K blocks.
> (But I won't be extending the block count in my first revision.)

Good idea, but pointless for now. You'd need to solve 2 other
serious ext2 limits first:

1. The entire filesystem is limited to 4 giga-blocks. There are
32-bit block numbers stored in the inode and indirect blocks.

2. Triple indirect blocks will stop you very quickly. You would
need to increase the block size to 8 kB before the 32-bit block
count becomes an issue. Linux doesn't support 8 kB blocks.
You could add quadruple-indirect blocks instead, but that is slow.

Here is that graph:

End result: ext2 with 64-bit file sizes and 4 kB blocks still has a
maximum theoretical limit of 4 TB. Adding quadruple-indirect blocks
won't make much of a difference because of the 32-bit block numbers
stored all over the disk will stop you at 16 TB. Increasing the
block size to 8 kB might be useful, but past that you only get 1 bit
of file size for every additional bit of block size.

Going to 8 kB blocks might be dangerous, since somebody would have
to debug rare overflow conditions with terabytes of real (not holes)
data. As it is, somebody will need to verify that overflowing the
triple-indirect block limit is safe.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:41    [W:0.093 / U:11.584 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site