Hi Andreas,
> 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?
> 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.
--
Takashi Sato
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.