LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Jörn Engel" <joern@lazybastard.org>
To: Juan Piernas Canovas <piernas@ditec.um.es>
Cc: Sorin Faibish <sfaibish@emc.com>,
Bill Davidsen <davidsen@tmr.com>,
Jan Engelhardt <jengelh@linux01.gwdg.de>,
kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation
Date: Tue, 20 Feb 2007 00:30:59 +0000 [thread overview]
Message-ID: <20070220003059.GJ7813@lazybastard.org> (raw)
In-Reply-To: <Pine.LNX.4.61.0702190625270.8828@ditec.inf.um.es>
On Tue, 20 February 2007 00:57:50 +0100, Juan Piernas Canovas wrote:
>
> I understand the problem that you describe with respect to the GC, but
> let me explain why I think that it has a small impact on DualFS.
>
> Actually, the GC may become a problem when the number of free segments is
> 50% or less. If your LFS always guarantees, at least, 50% of free
> "segments" (note that I am talking about segments, not free space), the
> deadlock problem disappears, right? This is a quite naive solution, but it
> works.
I don't see how you can guarantee 50% free segments. Can you explain
that bit?
> In a traditional LFS, with data and meta-data blocks, 50% of free segments
> represents a huge amount of wasted disk space. But, in DualFS, 50% of free
> segments in the meta-data device is not too much. In a typical Ext2,
> or Ext3 file system, there are 20 data blocks for every meta-data block
> (that is, meta-data blocks are 5% of the disk blocks used by files).
> Since files are implemented in DualFS in the same way, we can suppose the
> same ratio for DualFS (1).
This will work fairly well for most people. It is possible to construct
metadata-heavy workloads, however. Many large directories containing
symlinks or special files (char/block devices, sockets, fifos,
whiteouts) come to mind. Most likely noone of your user will ever want
that, but a malicious attacker might.
That, btw, brings me to a completely unrelated topic. Having a fixed
ratio a metadata to data is simple to implement, but allowing this ratio
to dynamically change would be nicer for administration. You can add
that to the Christmas wishlist for the nice boys, if you like.
> Remember, I am supposing a naive implementation of the cleaner. With a
> cleverer one, the meta-data device can be smaller, and the amount of
> disk space finally wasted can be smaller too. The following paper proposes
> some improvements:
>
> - Jeanna Neefe Matthews, Drew Roselli, Adam Costello, Randy Wang, and
> Thomas Anderson. "Improving the Performance of Log-structured File
> Systems with Adaptive Methods". Proc. Sixteenth ACM Symposium on
> Operating Systems Principles (SOSP), October 1997, pages 238 - 251.
>
> BTW, I think that what they propose is very similar to the two-strategies
> GC that you propose in a separate e-mail.
Will have to read it up after I get some sleep. It is late.
> The point of all the above is that you must improve the common case, and
> manage the worst case correctly. And that is the idea behind DualFS :)
A fine principle to work with. Surprisingly, what is the worst case for
you is the common case for LogFS, so maybe I'm more interested in it
than most people. Or maybe I'm just more paranoid.
Anyway, keep up the work. It is an interesting idea to pursue.
Jörn
--
He who knows that enough is enough will always have enough.
-- Lao Tsu
next prev parent reply other threads:[~2007-02-20 0:35 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <op.tnkdlbgsrwwil4@brcsmondepl2c.corp.emc.com>
2007-02-14 21:10 ` sfaibish
2007-02-14 21:57 ` Jan Engelhardt
2007-02-15 18:38 ` Juan Piernas Canovas
2007-02-15 20:09 ` Jörn Engel
2007-02-15 22:59 ` Juan Piernas Canovas
2007-02-16 9:13 ` Jörn Engel
2007-02-16 11:05 ` Benny Amorsen
2007-02-16 23:47 ` Bill Davidsen
2007-02-17 15:11 ` Jörn Engel
2007-02-17 18:10 ` Bill Davidsen
2007-02-17 18:36 ` Jörn Engel
2007-02-17 20:47 ` Sorin Faibish
2007-02-18 5:59 ` Jörn Engel
2007-02-18 12:46 ` Jörn Engel
2007-02-19 23:57 ` Juan Piernas Canovas
2007-02-20 0:10 ` Bron Gondwana
2007-02-20 0:30 ` Jörn Engel [this message]
2007-02-21 4:36 ` Juan Piernas Canovas
2007-02-21 12:37 ` Jörn Engel
2007-02-21 18:31 ` Juan Piernas Canovas
2007-02-21 19:25 ` Jörn Engel
2007-02-22 4:30 ` Juan Piernas Canovas
2007-02-22 16:25 ` Jörn Engel
2007-02-22 19:57 ` Juan Piernas Canovas
2007-02-23 13:26 ` Jörn Engel
2007-02-24 22:35 ` Sorin Faibish
2007-02-25 2:41 ` Juan Piernas Canovas
2007-02-25 12:01 ` Jörn Engel
2007-02-26 3:48 ` Juan Piernas Canovas
2007-02-20 20:43 ` Bill Davidsen
2007-02-15 20:38 ` Andi Kleen
2007-02-15 19:46 ` Jan Engelhardt
2007-02-16 1:43 ` sfaibish
2007-02-15 21:09 ` Juan Piernas Canovas
2007-02-15 23:57 ` Andi Kleen
2007-02-16 4:57 ` Juan Piernas Canovas
2007-02-26 11:49 ` Yakov Lerner
2007-02-26 13:08 ` Matthias Schniedermeyer
2007-02-26 13:24 ` Sorin Faibish
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=20070220003059.GJ7813@lazybastard.org \
--to=joern@lazybastard.org \
--cc=davidsen@tmr.com \
--cc=jengelh@linux01.gwdg.de \
--cc=linux-kernel@vger.kernel.org \
--cc=piernas@ditec.um.es \
--cc=sfaibish@emc.com \
--subject='Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation' \
/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
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).