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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.