As you may have read, Next3 release 1.0.11 automatically migrates to
new on-disk format.
Also, I would like to ask you again to promote Next3/Ext4 merge as a
topic on LSF,
if you think it is an appropriate topic.
My on-disk format change request is to re-assign a ro_compat feature
for IS_SNAPSHOT (currently in s_flags).
The reason for this request is the following scenario, which was
posted on next3-users list:
"If I use dd to restore a full snapshot image to another volume, can I
mount it as Next3?"
The answer to this question is that read-only mount is ok, but for
fsck needs to be run first to fix the free blocks counters.
The restored image is identified with the IS_SNAPSHOT flag.
If it was a ro_compat feature, it would prevent users from mistakingly
mounting it read-write before the fix.
Also, 'tune2fs -O ^is_snapshot' could be used to fix the counters,
without running full fsck.
Please assign me a constant for the feature if you agree,
OK, so in addition to:
#define EXT4_FEATURE_RO_COMPAT_HAS_SNAPSHOT 0x0080
You would also like:
#define EXT4_FEATURE_RO_COMPAT_IS_SNAPSHOT 0x0100
which is a feature flag that the kernel will never support, since this
is a hint that snapshot should only be mounted read-only, correct?
I am pinging you on this old request of mine... and modifying my
request slightly (to an incompatible feature).
I would like to have EXT4_FEATURE_INCOMPAT_IS_SNAPSHOT,
which will be set only inside snapshot images.
This is to say that Ext4 snapshots can only be mounted by Ext4 with
'snapshot mount' support.
One of the important applications of 'snapshot mount' incompatible
support is to deny read access
to snapshot files (or more generally excluded files) entires inside a snapshot.
This issue is currently handled by clearing all old snapshot inode
copies on snapshot take time.
It is a sub optimal solution, which was imposed by the design to mount
Next3 snapshot as Ext2
and it is not scalable to a large number of 'excluded' files.