From: Christian Stroetmann <stroetmann@ontolinux.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Dave Chinner <david@fromorbit.com>,
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 18:30:46 +0200 [thread overview]
Message-ID: <538DF836.5000206@ontolinux.com> (raw)
In-Reply-To: <20140603145749.GB12890@thunk.org>
On the 3rd of June 2014 16:57, Theodore Ts'o wrote:
> On Tue, Jun 03, 2014 at 07:30:32AM +0200, Christian Stroetmann wrote:
>> 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.
> Well, if you want to try to implement something like this, go for it!
I am already active since some weeks.
> I'd be very curious to see how well (a) how much CPU overhead it takes
> to crunch on a dependency graph with billions of vertices, and (b) how
> easily can it be to express these dependencies and maintainable such a
> dependency language would be. Sounds like a great research topic, and
To a) A run is expected to take some few hours on a single computing node.
Also, such a graph processing must not be done all the time, but only if
a new application demands a specific handling of the data in respect to
e.g. one of the ACID criterias. That is the reason why I put
"on-the-fly" in paranthesis.
To b) I hoped that file system developers could make some suggestions or
point to some no-gos.
I am also thinking about Petri-Nets in this relation, though it is just
an idea.
I would also like to mention that it could be used in conjunction with
Non-Volatile Memory (NVM) as well.
> I'll note the Call For Papers for FAST 2015 is out, and if you can
> solve these problems, it would make a great FAST 2015 submission:
>
> https://www.usenix.org/conference/fast15/call-for-papers
Are you serious or have I missed the 1st of April once again?
Actually, I could only write a general overview about the approach
comparable to a white paper, but nothing more.
> Cheers,
>
> - Ted
>
Best regards
Christian
prev parent reply other threads:[~2014-06-03 16: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
2014-06-03 14:57 ` Theodore Ts'o
2014-06-03 16:30 ` Christian Stroetmann [this message]
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=538DF836.5000206@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 \
--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).