All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: linux-kernel@vger.kernel.org
Cc: Juan Piernas Canovas <piernas@ditec.um.es>,
	Jan Engelhardt <jengelh@linux01.gwdg.de>,
	sfaibish <sfaibish@emc.com>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation
Date: Fri, 16 Feb 2007 18:47:48 -0500	[thread overview]
Message-ID: <45D642A4.5010009@tmr.com> (raw)
In-Reply-To: <20070216091321.GA28092@lazybastard.org>

Jörn Engel wrote:
> On Thu, 15 February 2007 23:59:14 +0100, Juan Piernas Canovas wrote:
>> Actually, the version of DualFS for Linux 2.4.19 implements a cleaner. In 
>> our case, the cleaner is not really a problem because there is not too 
>> much to clean (the meta-data device only contains meta-data blocks which 
>> are 5-6% of the file system blocks; you do not have to move data blocks).
> 
> That sounds as if you have not hit the "interesting" cases yet.  Fun
> starts when your device is near-full and you have a write-intensive
> workload.  In your case, that would be metadata-write-intensive.  For
> one, this is where write performance of log-structured filesystems
> usually goes down the drain.  And worse, it is where the cleaner can
> run into a deadlock.
> 
> Being good where log-structured filesystems usually are horrible is a
> challenge.  And I'm sure many people are more interested in those
> performance number than in the ones you shine at. :)
> 
Actually I am interested in the common case, where the machine is not 
out of space, or memory, or CPU, but when it is appropriately sized to 
the workload. Not that I lack interest in corner cases, but the "running 
flat out" case doesn't reflect case where there's enough hardware, now 
the o/s needs to use it well.

The one high load benchmark I would love to see is a web server, running 
tux, with a load over a large (number of files) distributed data set. 
The much faster tar create times posted make me think that a server with 
a lot of files would benefit, when CPU and memory requirements are not a 
bottleneck.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot


  parent reply	other threads:[~2007-02-16 23:45 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-11  3:06 [ANNOUNCE] DualFS: File System with Meta-data and Data Separation Sorin Faibish
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 [this message]
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
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
  -- strict thread matches above, loose matches on Subject: below --
2007-02-17  3:44 Adam J. Richter
2007-02-17  3:59 Adam J. Richter

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=45D642A4.5010009@tmr.com \
    --to=davidsen@tmr.com \
    --cc=jengelh@linux01.gwdg.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=piernas@ditec.um.es \
    --cc=sfaibish@emc.com \
    /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.