From: Eric Sandeen Subject: Re: [PATCH RFC 00/30] Ext4 snapshots - core patches Date: Mon, 06 Jun 2011 10:31:33 -0500 Message-ID: <4DECF2D5.7050408@redhat.com> References: <1304959308-11122-1-git-send-email-amir73il@users.sourceforge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lukas Czerner , linux-ext4@vger.kernel.org, tytso@mit.edu To: "Amir G." Return-path: Received: from mx1.redhat.com ([209.132.183.28]:9763 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757506Ab1FFPbx (ORCPT ); Mon, 6 Jun 2011 11:31:53 -0400 In-Reply-To: Sender: linux-ext4-owner@vger.kernel.org List-ID: On 6/6/11 9:32 AM, Amir G. wrote: > On Mon, Jun 6, 2011 at 4:08 PM, Lukas Czerner wrote: >> On Mon, 9 May 2011, amir73il@users.sourceforge.net wrote: >>> >>> MERGING >>> ------- >>> These patches are based on Ted's current master branch + alloc_semp removal >>> patches. Although the alloc_semp removal is an independent (and in my eyes >>> a good) change, it is also required by snapshot patches, to avoid circular >>> locking dependency during COW allocations. >>> >>> Merging with Allison's punch holes patches should be straight forward, since >>> the hard part, namely Yongqiang's split extent refactoring patches, was >>> already merged by Ted. >>> >>> Merging with Ted's big alloc patches is going to be a bit more challenging, >>> since big alloc patches make a lot of renaming and refactoring. However, >>> since has_snapshots and big_alloc features will never work together, >>> at least testing the code together is not a big concern. >> >> Hi Amir, >> >> what is the reason for the snapshots to never work with big_alloc ? Just >> out of curiosity. >> > > For one reason, a snapshot file format is currently an indirect file > and big_alloc > doesn't support indirect mapped files. > I am not saying it cannot be done, but if it does, there would be > several obstacles > to cross. I know I'm kind of just throwing a bomb out here, but I am very concerned about the ever-growing feature (in)compatibility matrix in ext4. Take for example dioread_nolock caveats: "However this does not work with nobh option and the mount will fail. Nor does it work with data journaling and dioread_nolock option will be ignored with kernel warning. Note that dioread_nolock code path is only used for extent-based files." If ext4 matches the lifespan of ext3, in 10 years I fear that it will look more like a collection of various individuals' pet projects, rather than any kind of well-designed, cohesive project. How long can we really keep adding features which are semi- or wholly- incompatible with other features? Consider this a cry in the wilderness for less rushed feature introduction, and a more holistic approach to ext4 design... -Eric