> It would also be a Very Good Idea, BTW, to require that the ext2fs
> filesystem version number be incremented before files larger than 4G
> be allowed in a given filesystem. Otherwise, when that fs is mounted
> by an older kernel, Bad Thing May Happen.
We made sure before 2.0 went out the door that ext2fs had a mechanism to
protect us from things like this. There is a set of capability bitmaps
in the ext2fs superblock which are checked by all kernels, and which
allow us to expand the capabilities of ext2fs in a way which older
kernels can detect and avoid.
There are three capability bitmaps: s_feature_compat, s_feature_incompat
and s_feature_ro_compat. The compatible mask is used to describe
filesystems running extensions which can be safely ignored by older
kernels, but which cannot be ignored by e2fsck; this set is probably
most useful for filesystem performance optimisations which don't affect
the on-disk layout, but whose presence needs to be detected by the
kernel in order for them to be useful.
The incompatible feature set describes features which a kernel simply
cannot deal with; if an unrecognised incompatible feature bit is set in
the superblock then all 2.0+ kernels will simply refuse to mount the
filesystem. The ro-compat bitmap is similar except that an older kernel
is allowed to mount the filesystem readonly, but not to modify it.
We can safely allocate one or two of the bits for large file
extensions. The best way is probably to use a fully compatible bit to
enable large files, and an incompatible bit to indicate the presence of
large files. That way we can set the bit by default on new filesystems,
but we still have a way of preventing large files on filesystems where
sharing between kernel versions is important. We can set the
large-file-presence bit whenever the first file on the filesystem
actually exceeds 2GB, so only filesystems which do actually contain
large files get barred from mounting by older kernels.
Cheers,
Stephen.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu