Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756365Ab1FHPd1 (ORCPT ); Wed, 8 Jun 2011 11:33:27 -0400 Received: from mail-ww0-f44.google.com ([74.125.82.44]:53188 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752854Ab1FHPdZ convert rfc822-to-8bit (ORCPT ); Wed, 8 Jun 2011 11:33:25 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Wx4UlAd+UaVTcrchacZAaSycanSblogOB+Vf1HAN/n4IvJmv/jsPBBIudxVl+AuwyE gVAE7AvKNSdyvekuIilR1h39e8IwRzQOauywu3qZyO4VjbfK30TgPNFF+k+DfhrJQ6kf gTKubaGetfS8aroSGn5JgEQaJiyjj2Jv8BNzI= MIME-Version: 1.0 In-Reply-To: <4DEF93CB.60507@redhat.com> References: <1307459283-22130-1-git-send-email-amir73il@users.sourceforge.net> <4DEF8A1D.2080707@redhat.com> <4DEF93CB.60507@redhat.com> Date: Wed, 8 Jun 2011 18:33:21 +0300 X-Google-Sender-Auth: e667qCCXBdwIAa1Fc4EJKcybHKg Message-ID: Subject: Re: [PATCH v1 00/30] Ext4 snapshots From: "Amir G." To: Eric Sandeen Cc: Lukas Czerner , linux-ext4@vger.kernel.org, tytso@mit.edu, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4712 Lines: 110 On Wed, Jun 8, 2011 at 6:22 PM, Eric Sandeen wrote: > On 6/8/11 10:01 AM, Amir G. wrote: >> On Wed, Jun 8, 2011 at 5:41 PM, Eric Sandeen 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/