|| ||Eric Sandeen <sandeen-AT-redhat.com> |
|| ||"Amir G." <amir73il-AT-users.sourceforge.net> |
|| ||Re: [PATCH RFC 00/30] Ext4 snapshots - core patches |
|| ||Mon, 06 Jun 2011 10:31:33 -0500|
|| ||Lukas Czerner <lczerner-AT-redhat.com>, linux-ext4-AT-vger.kernel.org,
|| ||Article, Thread
On 6/6/11 9:32 AM, Amir G. wrote:
> On Mon, Jun 6, 2011 at 4:08 PM, Lukas Czerner <email@example.com> wrote:
>> On Mon, 9 May 2011, firstname.lastname@example.org wrote:
>>> 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...
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)