Re: Re: [RFC] 48bit support for extents

Hi,

On Fri, 2006-05-19 at 13:30 -0600, Andreas Dilger wrote:

> If we are checking that the filesystem itself is <= 32-bit block numbers
> at mount time, then the only case where the i_file_acl_high can be
> non-zero is with disk corruption.  

Or if we make an error in the various permutations of the compatibility
logic.  It's in order to find such mistakes early that I'd like us to
check for such things in the code.

> My preference is to notice this but
> continue operating (i.e. not so serious as an ext3_error(), since that
> might turn the filesystem read-only), since we don't actually depend on
> that data in any way.

If we notice on-disk corruption then going read-only early and avoiding
any potential spread of the problem is the better option, I think. 

> The bad i_file_acl_high should get wiped out if the inode is modified (the
> code should always be writing the high bits of all fields I think), which
> is preferrable to leaving garbage there and finding out later when the
> filesystem is resized beyond 8TB that it grabs some (now seemingly valid)
> garbage.
> 
> It may well also be that e2fsck hasn't been checking any of these
> fields since day 0, because they are unused so they may contain garbage
> of some ancient vintage.

True.

--Stephen




-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642