linux-ext4 - Re: [PATCH RFC 00/30] Ext4 snapshots

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 06 Jun 2011 10:31:33 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	"Amir G." <amir73il@...rs.sourceforge.net>
CC:	Lukas Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org,
	tytso@....edu
Subject: Re: [PATCH RFC 00/30] Ext4 snapshots - core patches

On 6/6/11 9:32 AM, Amir G. wrote:
> On Mon, Jun 6, 2011 at 4:08 PM, Lukas Czerner <lczerner@...hat.com> wrote:
>> On Mon, 9 May 2011, amir73il@...rs.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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html