On Wed, Mar 14, 2012 at 03:34:13PM +0100, Lukas Czerner wrote:
> >
> > You can make it be a RO_COMPAT change instead of an INCOMPAT change,
> > yes.
>
> Does it have to be RO_COMPAT change though ? Since this would be both
> forward and backward compatible.
The challenge is how do you notice if the file system is mounted on an
older kernel, which then inserts a directory entry without updating
the secondary tree. The older kernel won't know about the new inode
flag, so it can't clear the flag when it modifies the directory.
We were able to get away with making the original htree feature
read/write compatible because the design for it was anticipated far in
advance, and because it was before the days of enterprise kernels that
had to be supported for seven years. So we added code into ext3 to
clear the the htree flag whenever the directory was modified something
like two years before the htree code made its appearance, and back
then we decided that was fair to assume no one would be using a kernel
that old, or be jumping back and forth between an ancient kernel and a
modern kernel with htree enabled. Yes, that was playing a bit fast
and loose, but early on in the kernel history, we could do that. It's
not something I would do today.
The bigger deal is that as Zach pointed out, we can't just index it by
inode number because we have to worry about hard links. Which means
we need either an explicit counter field added to the directory entry,
or some kind of new offset field. That we can't just shoehorn in and
retain backwards compatibility.
And once we break backwards compatibility, we might as well look at
the full design space and see what is the most optimal.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
