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

On May 19, 2006  17:50 +0100, Stephen C. Tweedie wrote:
> > +	if ((sizeof(sector_t) > 4) &&
> > +	    (EXT3_SB(inode->i_sb)->s_es->s_creator_os != EXT3_OS_HURD))
> > +		ei->i_file_acl |=
> > +			((__u64)le16_to_cpu(raw_inode->i_file_acl_high)) << 32;
> 
> One question: if we're in 32-bit mode (either because we have already
> determined that the fs has no 64-bit extension, or because sizeof
> (sector_t) == 4), should we simply ignore i_file_acl_high, or should we
> read it and test for zero?

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.  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.

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.

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



-------------------------------------------------------
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