Re: [PATCH v1 00/30] Ext4 snapshots

["Amir G." <amir73il@users.sourceforge.net>]

On Wed, Jun 8, 2011 at 6:22 PM, Eric Sandeen <sandeen@redhat.com> wrote:
> On 6/8/11 10:01 AM, Amir G. wrote:
>> On Wed, Jun 8, 2011 at 5:41 PM, Eric Sandeen <sandeen@redhat.com> wrote:
>>> On 6/8/11 9:04 AM, Amir G. wrote:
>>>>> And one last note, I also think that the snapshot format change in the
>>>>>> future, when we'll have snpashots with 64bit feature compatible seems
>>>>>> just wrong to me. Adding some features or changing the implementation a
>>>>>> bit is ok, but format change is different. When the code is upstream and
>>>>>> stable it is just wrong.
>>>> What can I say, I understand why it looks bad, but is 64bit code
>>>> upstream and stable? Hell no! e2fsprogs 64bit is not out yet!
>>>> There is no reason to call it 'format change'.
>>>> It's going to be a new format used only for 64bit fs, which are not
>>>> even out there yet. And when they are finally out there, they won't
>>>> have
>>>> snapshots until the new format is implemented.
>>>
>>> Well, the on-disk format for 64-bit (48-bit?) ext4 is there & fixed; it's
>>> just that there is no released userspace which can properly handle it, right?
>>
>> I don't know, you tell me.
>> Are there many users out there using 64bit feature, without the proper
>> user space tools?
>
> No, but that doesn't mean the disk format has to change when the tools
> come out... I just don't want to confuse "there are no tools" with
> "the disk format is unstable" - Andreas et. al. have been using
> that format for years.
>
>>>
>>> I don't anticipate ext4 format changes for >16T, or am I missing something?
>>>
>>> -Eric
>>>
>>
>> Argh! I wish I hadn't missed the Monday call (it's
>> not in a good time for me).
>> This whole 'format change' has gone out of control
>> and I find it hard to present my case properly on scattered emails.
>
> Sorry; I may have just misunderstood...
>
>> The message I am trying to get through is:
>> There is 32bit snapshot file format, which is implemented and well tested.
>> There is 64bit snapshot file format, which is not implemented yet, so
>> 64bit and snapshot feature are mutually exclusive.
>> If and when 64bit snapshot file format will be implemented, it will be
>> a new type of extent mapped file (v2) with 48bit logical addresses.
>> Is this a 'format change'? Call it what you will, but it shouldn't
>> affect anything on existing structures. It should only affect the
>> non-existing structure of 64bit snapshot file.
>>
>> Does this answer your question?
>
> Yes, I guess I had misunderstood your point; I thought you were
> implying that ext4's format had to change to support 64-bit, so why
> not change snapshots along with it....
>
> But you're just saying that you wish to push 32-bit snapshots which only
> work with certain sizes of ext4 filesystems now, and later you will
> release a new snapshot format which works with the larger filesystems.
> Right?

Right. Where 'Larger filesystems' := 64bit block addresses.

>
> (I don't actually know if we'll ever have 64-bit ext4, though, there
> are still so many scaling issues beyond just being able to mkfs,
> mount, growfs etc ... it's a serious game of catch-up with xfs
> in that space, IMHO, which has been doing it well for years now...)

More of a good reason to push a snapshot file format that work well
with 32bit ext4.

>
> Still, pushing snapshots upstream which will have an on-disk format
> more limited than the rest of the filesystem's on-disk format
> does strike me as suboptimal from a pure technical design POV.
>
> What if we proposed, say, xattr code that could only apply xattrs
> to files located in the first 16T?  I don't think it'd be accepted.

That is not a correct analogy. The correct analogy is not supporting
xattrs on 64-bit ext4. Whether it makes sense or not for snapshots
depends IMHO on whether people find snapshot on 32bit ext4 only
useful or not.

I naturally think that people will find it useful.
Anyone can add snapshots to his existing 32-bit ext4,
No one can migrate the same fs to 64-bit...

>
> I understand that you have a history and a format and a business case,
> but that really should not change whether we do it right the first time,
> upstream, IMHO...  But I'm just the peanut gallery, here....  ;)
>
> -Eric
>
>> 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
>
>
--
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