On Wed, Sep 12, 2007 at 12:45:37PM -0400, Theodore Tso wrote:
>On Wed, Sep 12, 2007 at 10:26:50AM +0100, Steve McIntyre wrote:
>> 
>> If I add -O ^dir_index to the options given to mke2fs, this all works
>> fine again and reports no changes from e2fsck. Equally, using older
>> versions of the e2fs tools on older machines works fine; I'm assuming
>> that's because they don't support/enable dir_index by default. Hence
>> my suggestion that the dir_index flag is responsible. If e2fsck will
>> only re-org corrupt directories then that suggests we're seeing real
>> corruption.
>
>Actually, I had forgotten that e2fsck will also re-index (or more
>properly, add the htree index) to a directory which is not indexed at
>all AND indexing would help it (the number of blocks is >= 3) AND if
>the dir_index feature is enabled AND if the filesystem is opened
>read/write (i.e., if -n is not specified).  This isn't documented in
>the man page, but neither is it contradicted by the man page, which
>merely states that -D requests that ALL of the directories be optimised.

OK.

>I'll add some additional explanatory text to the man page, but my
>suggestion to you would be change the script to recognize that exit
>status less than 4 does not mean that the filesystem is corrupt.
>Also, if you're really never going to be using the filesystem on an
>ext3 filesystem, you might as well add -O ^dir_index to mke2fs. 

Oh, absolutely. We've already done that, and changed the fsck args
from -fy to -fn as well. Then if we ever get an error from fsck, we
know we've found a real problem and aborting the build is the correct
solution. I was more worried by your comment that we might be seeing
real corruption! :-)

>I actually do want to rethink how mke2fs asks users to specify ext2
>vs. ext3.  These days, ext3 should be the default, so it's silly to
>require most users to specify -j.  But maybe if they really want an
>ext2 filesystem we shouldn't be enabling dir_index.  And of course,
>if I make any change to mke2fs's command line system, it needs to be
>backwards compatible with current scripts and user expectations.
>Heh; this isn't going to trivial to design.

Agreed; breaking things here is a quick way to annoy lots of
people... :-)

-- 
Steve McIntyre, Amino                                 [EMAIL PROTECTED]
 
"C++ ate my sanity" -- Jon Rabone




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to