Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Eric Sandeen <sandeen <at> redhat.com>
Subject: Re: [PATCH RFC 00/30] Ext4 snapshots - core patches
Newsgroups: gmane.comp.file-systems.ext4
Date: Monday 6th June 2011 15:31:33 UTC (over 6 years ago)
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, [email protected] 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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
CD: 3ms