Re: [Ext2-devel] [PATCH 1/4] ext2/3: Extends the max file size(ext2 in kernel)

[Andreas Dilger <adilger@clusterfs.com>]

On Mar 20, 2006  21:21 +0900, Takashi Sato wrote:
> >Instead of breaking all filesystems that need to create large files,
> >the patch should instead set "i_flags | EXT2_LARGEBLK_FL" only on inodes
> >that are larger than 2TB and use "blocksize" i_blocks on those files.
> 
> Do you have any idea when the flag is set and cleared?

You would set this flag when the file grows over 2^32 sectors in size.
You might optionally clear it if the file shrinks below 2^32 sectors.
At that time you would take the old i_blocks value and (>> (blockbits - 9)).

> >This preserves compatibility with existing filesystems and doesn't
> >impose any breakage opon an existing filesystem for anyone who wants
> >to use this feature.
> 
> I'm afraid that i_blocks of >2TB file would be corrupted if old kernel
> or old e2fsprogs touches the file.

I don't mean that we would remove the COMPAT flag (Ted and I arE just
having a discussion in another thread whether i_blocks inaccuracy
should be an ROCOMPAT or INCOMPAT feature)).  If a kernel understands
the {RO,IN}COMPAT_LARGE_BLOCK flag, then they would also understand
EXT2_LARGEBLK_FL on the inode to mean "i_blocks is in fs-blocksize units",
so no corruption would take place.  If the kernel can't understand the
COMPAT flag, it would not mount (INCOMPAT, which is inconvenient for the
users) or mount read-only (ROCOMPAT, wouldn't allow file to be modified).
The same is true for e2fsprogs.

The real goal is that setting ?COMPAT_LARGE_BLOCK doesn't immediately
make all OTHER files in the filesystem have incorrect i_blocks values,
which would be MUCH more of a problem than files > 2TB having inaccurate
i_blocks counts.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.