Re: ReiserFS Maximum file size (in practice)

[Jeff Mahoney <jeffm@suse.com>]

Chris Mason wrote:
> We can probably talk Jan Kara into fixing dquot_transfer, and probably
> talk Andrew Morton into allowing a resolution on the inode->i_bytes
> mess.  ext2/3 suffer from the same problem (read ext[23]_max_size).

The comment on ext[23]_max_size doesn't only refer to the in-memory 
i_blocks, but also to the on-disk one as well. Unlike ReiserFS, Ext[23] 
doesn't track blocks as a multiple of the filesystem block size. It 
tracks it as a multiple of 512B blocks, just like the in memory one. 
(see ext[23]_read_inode and ext[23]_do_update_inode; There's no 
blocksize translation)

ReiserFS is artificially limited by the VFS layer (and in its own use of 
i_blocks to update stat_data->sd_blocks); Ext[23] is limited by its own 
disk format. Other than its i_blocks, ext[23]'s triple indirection 
should be able to support files up to ~ 4TB.


> I think I'd rather just fix the quota problem right now, it's a smaller
> change.

I think there's going to be a decent amount of work in either case. 
Definately moreso than the patch I posted earlier. There are two scenarios:

1) Fix just reiserfs. This means adding a sd_blocks field to the 
in-memory inode, increasing every reiserfs inode by 4 bytes. It also 
means that every time a quota operation occurs, we need to follow it 
with an update to our internal block count as well. It's easy enough to 
do, just not pretty.

2) Fix the VFS layer. Fixing the VFS layer is simple, but there are 
filesystems that assume i_blocks is 32-bit already and they'd need to be 
cleaned up also.

Unfortunately, all this may be a moot point anyway. If a file is created 
on a kernel supporting file sizes > 2 TB, and is then updated on a 
previous kernel, wrapping will occur and cause breakage.

-Jeff

-- 
Jeff Mahoney
SuSE Labs