Re: [rfc, patch 0/3] larger block group descriptors

On Jun 08, 2006  09:45 +0200, Laurent Vivier wrote:
> > In the existing Bull patches RO_COMPAT_64BIT is used, but I don't think
> > this is a safe read-only compat change, since an old kernel will just use
> > s_blocks_count and not s_blocks_count_hi, truncating potentially a very
> > large part of the filesystem.
> 
> I put RO_COMPAT to allow an old kernel to retrieve a part of data (when _hi
> part is 0) if needed. But I have no definitive idea on this, if you think
> INCOMPAT_ is better I have no objection to use it.

Hmm, but if _hi part is 0 then why would RO_COMPAT_64BIT be set?  I'm just
worried about a case where filesystem is (2^32 + 256 blocks) and older
kernels will consider this filesystem to be 256 blocks in size.  Some users
might consider their filesystem completely corrupted at this point (all they
would get is a lot of errors accessing files) and reformat or something...

I looked through the code, and the one critical part where the blocks count
is used on a read-only filesystem is ext3_read_inode->ext3_get_inode_block()
because the s_group_desc array depends on s_blocks_count, so we won't have
read the group descriptors for groups at the end of the filesystem.  Otherwise
we would be able to read file data beyond s_blocks_count up to 16TB.

So, unfortunately this change needs to be an INCOMPAT one, but since the
extents format is also needed to address files beyond 16TB it isn't a big
deal.  I'd still want to make this a separate INCOMPAT_64BIT flag because
there is no reason why extents can't be used on smaller filesystems, and
because CFS already has lots of installed systems using extents that don't
yet understand the 64-bit extensions.

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