From: Eric Sandeen <sandeen@redhat.com>
To: "Amir G." <amir73il@users.sourceforge.net>
Cc: Lukas Czerner <lczerner@redhat.com>,
linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH RFC 00/30] Ext4 snapshots - core patches
Date: Mon, 06 Jun 2011 10:31:33 -0500 [thread overview]
Message-ID: <4DECF2D5.7050408@redhat.com> (raw)
In-Reply-To: <BANLkTimjxkOnX6hvLvU+Xth20ie5FaXq1A@mail.gmail.com>
On 6/6/11 9:32 AM, Amir G. wrote:
> On Mon, Jun 6, 2011 at 4:08 PM, Lukas Czerner <lczerner@redhat.com> 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
next prev parent reply other threads:[~2011-06-06 15:31 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-09 16:41 [PATCH RFC 00/30] Ext4 snapshots - core patches amir73il
2011-05-09 16:41 ` [PATCH RFC 01/30] ext4: EXT4 snapshots (Experimental) amir73il
2011-06-06 14:50 ` Lukas Czerner
2011-06-07 9:28 ` Amir G.
2011-06-07 10:42 ` Lukas Czerner
2011-06-07 13:20 ` Amir G.
2011-05-09 16:41 ` [PATCH RFC 02/30] ext4: snapshot debugging support amir73il
2011-06-06 15:08 ` Lukas Czerner
2011-06-07 9:59 ` Amir G.
2011-06-07 10:49 ` Lukas Czerner
2011-05-09 16:41 ` [PATCH RFC 03/30] ext4: snapshot hooks - inside JBD hooks amir73il
2011-06-06 15:53 ` Lukas Czerner
2011-06-06 16:08 ` Amir G.
2011-06-06 19:01 ` Amir G.
2011-05-09 16:41 ` [PATCH RFC 04/30] ext4: snapshot hooks - block bitmap access amir73il
2011-05-09 16:41 ` [PATCH RFC 05/30] ext4: snapshot hooks - delete blocks amir73il
2011-06-07 11:24 ` Lukas Czerner
2011-06-07 13:24 ` Amir G.
2011-06-07 13:32 ` Lukas Czerner
2011-05-09 16:41 ` [PATCH RFC 06/30] ext4: snapshot hooks - move data blocks amir73il
2011-05-09 16:41 ` [PATCH RFC 07/30] ext4: snapshot hooks - direct I/O amir73il
2011-05-09 16:41 ` [PATCH RFC 08/30] ext4: snapshot hooks - move extent file data blocks amir73il
2011-05-09 16:41 ` [PATCH RFC 09/30] ext4: snapshot file amir73il
2011-06-02 11:52 ` Amir G.
2011-05-09 16:41 ` [PATCH RFC 10/30] ext4: snapshot file - read through to block device amir73il
2011-05-09 16:41 ` [PATCH RFC 11/30] ext4: snapshot file - permissions amir73il
2011-05-09 16:41 ` [PATCH RFC 12/30] ext4: snapshot file - store on disk amir73il
2011-05-09 16:41 ` [PATCH RFC 13/30] ext4: snapshot file - increase maximum file size limit to 16TB amir73il
2011-06-02 11:47 ` Amir G.
2011-06-03 0:48 ` Ted Ts'o
2011-06-03 4:45 ` Amir G.
2011-05-09 16:41 ` [PATCH RFC 14/30] ext4: snapshot block operations amir73il
2011-05-09 16:41 ` [PATCH RFC 15/30] ext4: snapshot block operation - copy blocks to snapshot amir73il
2011-05-09 16:41 ` [PATCH RFC 16/30] ext4: snapshot block operation - move " amir73il
2011-05-09 16:41 ` [PATCH RFC 17/30] ext4: snapshot control amir73il
2011-05-09 16:41 ` [PATCH RFC 18/30] ext4: snapshot control - fix new snapshot amir73il
2011-05-09 16:41 ` [PATCH RFC 19/30] ext4: snapshot control - reserve disk space for snapshot amir73il
2011-05-09 16:41 ` [PATCH RFC 20/30] ext4: snapshot journaled - increase transaction credits amir73il
2011-05-09 16:41 ` [PATCH RFC 21/30] ext4: snapshot journaled - implement journal_release_buffer() amir73il
2011-05-09 16:41 ` [PATCH RFC 22/30] ext4: snapshot journaled - bypass to save credits amir73il
2011-05-09 16:41 ` [PATCH RFC 23/30] ext4: snapshot journaled - trace COW/buffer credits amir73il
2011-05-09 16:41 ` [PATCH RFC 24/30] ext4: snapshot list support amir73il
2011-05-09 16:41 ` [PATCH RFC 25/30] ext4: snapshot race conditions - concurrent COW operations amir73il
2011-05-09 16:41 ` [PATCH RFC 26/30] ext4: snapshot race conditions - tracked reads amir73il
2011-05-09 16:41 ` [PATCH RFC 27/30] ext4: snapshot exclude - the exclude bitmap amir73il
2011-05-09 16:41 ` [PATCH RFC 28/30] ext4: snapshot cleanup amir73il
2011-05-09 16:41 ` [PATCH RFC 29/30] ext4: snapshot cleanup - shrink deleted snapshots amir73il
2011-05-09 16:41 ` [PATCH RFC 30/30] ext4: snapshot rocompat - enable rw mount amir73il
2011-06-06 13:08 ` [PATCH RFC 00/30] Ext4 snapshots - core patches Lukas Czerner
2011-06-06 14:32 ` Amir G.
2011-06-06 15:31 ` Eric Sandeen [this message]
2011-06-06 16:05 ` Lukas Czerner
2011-06-06 20:40 ` Ted Ts'o
2011-06-07 13:59 ` Ric Wheeler
2011-06-07 15:37 ` Ted Ts'o
2011-06-06 16:33 ` Andreas Dilger
2011-06-06 16:42 ` Eric Sandeen
2011-06-06 19:58 ` Lukáš Czerner
2011-06-06 18:25 ` Amir G.
2011-06-06 20:55 ` Ted Ts'o
2011-06-07 5:17 ` Andreas Dilger
2011-06-07 5:58 ` Amir G.
2011-06-07 10:09 ` Lukas Czerner
2011-06-07 13:01 ` Amir G.
2011-06-07 13:50 ` Ric Wheeler
2011-06-07 14:39 ` Amir G.
2011-06-07 6:40 ` Amir G.
2011-06-07 15:26 ` Josef Bacik
2011-06-07 16:46 ` Amir G.
2011-06-07 16:54 ` Josef Bacik
2011-06-07 18:22 ` Amir G.
2011-06-07 17:14 ` Sunil Mushran
2011-06-07 17:30 ` Ted Ts'o
2011-06-07 17:54 ` Amir G.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DECF2D5.7050408@redhat.com \
--to=sandeen@redhat.com \
--cc=amir73il@users.sourceforge.net \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).