Adding Roland McGrath to the CC.
> > It would also be good to understand what HURD is actually doing
> > with those other fields (if anything, does it even exist
> > anymore?), since it is literally holding TB of space unusable
> > on Linux ext3 filesystems that could better be put to use.
> > There are i_translator, i_mode_high, and i_author held hostage
> > by HURD, and I certainly have never seen or heard of any good
> > description of what they do or if Linux would/could ever use
> > them, or if HURD could live without them.
Hurd is definitely using the translator field, and I only recently
discovered they are using it to point at a disk block where the
name of the translator program (I'm not 100% sure, but I think it's
a generic, out-of-band, #! sort of functionality). I don't know
about the other fields, but I can find out.
Something like that. The author field is akin to gid/uid. I don't
recall the exact usage of i_mode_high, but it has something to do with
translators.
> If they really are 100% necessary for hurd, it might be that we
> could relegate them to an xattr. There's the slight problem of
> testing, though; does anyone on ext2-devel actually run hurd,
> ever?
Relegating them to an xatter would break compatibility with
existing hurd filesystems. We could take the arrogant "Linux is
the only thing that matters", and just screw them, and the net
result will probably be that Hurd will never implement some of the
advanced features we've been talking about. They might not
anyways, though. A real problem is that as far as I know, the hurd
ext2 developers aren't on the ext2-devel mailing list.
I've cc'ed two people that sent me a request to add some additional
debugfs functionality to support hurd; maybe they can help by
telling us whether or not hurd is using i_mode_high and i_author,
and whether or not hurd has any likelihood of tracking new ext3
features that we might add in the future or not.
Both i_mode_high and i_author are used in the Hurd. But they are only
used if and only if creator of the file-system is the Hurd, same for
the translator fields.
> > I'm fully in the "the chance of any real problem is vanishingly
> > small" camp, even though Lustre is one of the few users of
> > large inodes. The presence of the COMPAT field would not
> > really be any different than just changing ext3_new_inode() to
> > make i_extra_isize 16 by default, except to cause breakage
> > against the older e2fsprogs.
>
> Setting i_extra_isize will break older e2fsprogs anyway, won't
> it? e2fsck needs to have full knowledge of all fs fields in
> order to maintain consistency; if it doesn't know about some of
> the fields whose presence is implied by i_extra_isize, then
> doesn't it have to abort?
E2fsprogs previous to e2fsprogs 1.37 ignored i_extra_isize and
didn't check whether or not the EA's in the inode were valid.
Starting in e2fsprogs 1.37, e2fsck understands i_extra_size and in
fact does validate the EA's in the inode. If we add new i_extra
fields, then currently e2fsprogs will ignore them, and that's OK
for things like the high precision time fields. But if they are
fields where e2fsck does need to know about them, then obviously we
would need a COMPAT feature flag to signal that fact (since e2fsck
will refuse to operate on a filesystem if ther is a COMPAT feature
that it doesn't understand.)
> So for future-proofing, we do need some distinction between the
> fields actually *used* in i_extra_isize, and those simply
> reserved there. And that has to be per-inode, if we want to
> allow easy dynamic migration to newer fields.
>
> So a per-superblock field guaranteeing that there's at least $N
> bytes of usable *potential* i_extra_isize in each inode, and a
> per-inode i_extra_isize which shows which fields are *actively*
> used, gives us both pieces of information that we need.
The easiest way to do future-proofing is to state that they must be
initialized to zero. That's how we handle unusued fields in the
superblock, after all, and it means that it's relatively easy to
add new superblock fields without needing to cause compatibility
problems.. If you absolutely, positively need e2fsck to abort if
it doesn't understand a particular field, that's what a COMPAT
feature flag is for. Otherwise, new kernels can simply check to
see if the field is non-zero, and if so, honor it, and old-kernels
will simply ignore the new information. In many cases, that's more
than sufficient.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
