Next3 on-disk format change request

Next3 on-disk format change request

[Amir Goldstein]

Hi Ted,

As you may have read, Next3 release 1.0.11 automatically migrates to
new on-disk format.
(see http://next3.sf.net)

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
read-write mount,
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,
Thanks,
Amir.

Re: Next3 on-disk format change request

[tytso]

On Tue, Jun 22, 2010 at 01:30:54PM +0300, Amir Goldstein wrote:
> My on-disk format change request is to re-assign a ro_compat feature
> for IS_SNAPSHOT (currently in s_flags).

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?

						- Ted

Re: Next3 on-disk format change request

[Amir Goldstein]

On Thu, Jun 24, 2010 at 3:35 AM,  <tytso@mit.edu> wrote:
> On Tue, Jun 22, 2010 at 01:30:54PM +0300, Amir Goldstein wrote:
>> My on-disk format change request is to re-assign a ro_compat feature
>> for IS_SNAPSHOT (currently in s_flags).
>
> 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?
>

That is correct.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Next3 on-disk format change request

[Amir Goldstein]

On Thu, Jun 24, 2010 at 7:33 AM, Amir Goldstein <amir73il@gmail.com> wrote:
> On Thu, Jun 24, 2010 at 3:35 AM,  <tytso@mit.edu> wrote:
>> On Tue, Jun 22, 2010 at 01:30:54PM +0300, Amir Goldstein wrote:
>>> My on-disk format change request is to re-assign a ro_compat feature
>>> for IS_SNAPSHOT (currently in s_flags).
>>
>> 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?
>>
>
> That is correct.
>

Hi Ted,

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.

Thanks,
Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html