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, 6 Jun 2011 18:05:24 +0200 (CEST)
From:	Lukas Czerner <lczerner@...hat.com>
To:	Eric Sandeen <sandeen@...hat.com>
cc:	"Amir G." <amir73il@...rs.sourceforge.net>,
	Lukas Czerner <lczerner@...hat.com>,
	linux-ext4@...r.kernel.org, tytso@....edu
Subject: Re: [PATCH RFC 00/30] Ext4 snapshots - core patches

On Mon, 6 Jun 2011, Eric Sandeen wrote:

> 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...

Well, we can also start ditching some unused features and tunnables, or
make it default and remove it from documentation so people will not use
it and we can get rid of some of the options in the future. For examle 

orlov
oldalloc
bsddf
minixdf

seems like a good start from the first glance...

Thanks!
-Lukas

> 
> -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
> 
--
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