Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

[Bill Davidsen]

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@xxxxxxx>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

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