From: Christian Stroetmann <stroetmann@ontolinux.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Daniel Phillips <daniel@phunq.net>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Subject: Re: [RFC][PATCH 1/2] Add a super operation for writeback
Date: Tue, 03 Jun 2014 07:30:32 +0200 [thread overview]
Message-ID: <538D5D78.6040102@ontolinux.com> (raw)
In-Reply-To: <20140603033940.GB14410@dastard>
On the 3rd of June 2014 05:39, Dave Chinner wrote:
> On Mon, Jun 02, 2014 at 10:30:07AM +0200, Christian Stroetmann wrote:
>> When I followed the advice of Dave Chinner:
>> "We're not going to merge that page forking stuff (like you were
>> told at LSF 2013 more than a year ago:
>> http://lwn.net/Articles/548091/) without rigorous design review and
>> a demonstration of the solutions to all the hard corner cases it
>> has"
>> given in his e-mail related with the presentation of the latest
>> version of the Tux3 file system (see [1]) and read the linked
>> article, I found in the second comments:
>> "Parts of this almost sound like it either a.) overlaps with or b.)
>> would benefit greatly from something similar to Featherstitch
>> [[2]]."
>>
>> Could it be that we have with Featherstitch a general solution
>> already that is said to be even "file system agnostic"?
>> Honestly, I thought that something like this would make its way into
>> the Linux code base.
> Here's what I said about the last proposal (a few months ago) for
> integrating featherstitch into the kernel:
>
> http://www.spinics.net/lists/linux-fsdevel/msg72799.html
>
> It's not a viable solution.
>
> Cheers,
>
> Dave.
How annoying, I did not remember your e-mail of the referenced thread
"[Lsf-pc] [LSF/MM TOPIC] atomic block device" despite I saved it on
local disk. Thanks a lot for the reminder.
I also directly saw the problem with the research prototype
Featherstitch, specifically the point "All the filesystem modules it has
are built into the featherstitch kernel module, and called through a VFS
shim layer". But it is just a prototype and its concept of abstraction
has not to be copied 1:1 into the Linux code base.
In general, I do not believe that the complexity problems of soft
updates, atomic writes, and related techniques can be solved by
hand/manually. So my suggestion is to automatically handle the
complexity problem of e.g. dependancies in a way that is comparable to
a(n on-the-fly) file-system compiler so to say that works on a very
large dependancy graph (having several billions of graph vertices
actually). And at this point an abstraction like it is given with
Featherstitch helps to feed and control this special FS compiler.
Actually, I have to follow the discussion further on the one hand and go
deeper into the highly complex problem space on the other hand.
With all the best
Christian
next prev parent reply other threads:[~2014-06-03 5:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-01 21:41 [RFC][PATCH 1/2] Add a super operation for writeback Daniel Phillips
2014-06-01 21:42 ` [RFC][PATCH 2/2] tux3: Use writeback hook to remove duplicated core code Daniel Phillips
2014-06-02 3:30 ` Dave Chinner
2014-06-02 20:07 ` Daniel Phillips
2014-06-02 3:15 ` [RFC][PATCH 1/2] Add a super operation for writeback Dave Chinner
2014-06-02 20:02 ` Daniel Phillips
2014-06-03 3:33 ` Dave Chinner
2014-06-03 7:01 ` Daniel Phillips
2014-06-03 7:26 ` Daniel Phillips
2014-06-03 7:47 ` OGAWA Hirofumi
2014-06-03 8:12 ` Dave Chinner
2014-06-03 8:57 ` OGAWA Hirofumi
2014-06-03 7:52 ` Dave Chinner
2014-06-03 14:05 ` Jan Kara
2014-06-03 14:14 ` Christoph Hellwig
2014-06-03 14:25 ` Theodore Ts'o
2014-06-03 15:21 ` Jan Kara
2014-06-03 22:37 ` Daniel Phillips
2014-06-04 20:16 ` Jan Kara
2014-06-02 8:30 ` Christian Stroetmann
2014-06-03 3:39 ` Dave Chinner
2014-06-03 5:30 ` Christian Stroetmann [this message]
2014-06-03 14:57 ` Theodore Ts'o
2014-06-03 16:30 ` Christian Stroetmann
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=538D5D78.6040102@ontolinux.com \
--to=stroetmann@ontolinux.com \
--cc=akpm@linux-foundation.org \
--cc=daniel@phunq.net \
--cc=david@fromorbit.com \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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).