Well, it's hard to see how the fsck could hurt, since all the blocks of the
directory look like legitimate empty blocks. When did
> and it definitely won't validate the indexes, so a
> "successfull" fsck of an indexed directory doesn't mean anything until it
> can understand this COMPAT flag.
>
> That said, I agree that turning the COMPAT flag off for short term testing
> is probably not fatal, but I thought we were not going to even suggest
> using non-throwaway filesystems until the hash function was finalized?
True. Right now, I'm interested in finding out exactly how the old fscks are
going to behave when they run into indexed directories, so I'll leave the
COMPAT flag off for now and turn it back on when we hit the first
format-frozen release. The method of restoring a partition to a fsckable
state is easy to document:
# debugfs -w root_fs
debugfs: feature -dir_index
Anybody who's running the patch will have access to a recent version of
debugfs that knows about the dir_index flag.
> In
> the end, if an updated e2fsck detects the DIR_INDEX flag (and valid indexes
> therein) it will turn on the COMPAT flag for us, so all will be well. I
> don't advise that we push for patch inclusion until e2fsck is done, however.
Yes, as long as testers heed my warning and stick to test partitions there's
no particular danger. There's a simple recovery procedure for anyone who
doesn't want to bother re-mkfsing the partition. We're in pretty good shape.
My improved show_buckets routine is working code that could be used to get
started on the new fsck code. It walks the index in hash bucket order
dumping out statistics, and, together with the checks in dx_probe, basically
defines the index format.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/