linux-kernel - Re: [RFC][PATCH 1/2] Add a super operation for writeback

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:	Tue, 03 Jun 2014 18:30:46 +0200
From:	Christian Stroetmann <stroetmann@...olinux.com>
To:	Theodore Ts'o <tytso@....edu>
CC:	Dave Chinner <david@...morbit.com>,
	Daniel Phillips <daniel@...nq.net>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Subject: Re: [RFC][PATCH 1/2] Add a super operation for writeback

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/