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

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]

Message-ID:  <45D642A4.5010009@tmr.com>
Date:	Fri, 16 Feb 2007 18:47:48 -0500
From:	Bill Davidsen <davidsen@....com>
To:	linux-kernel@...r.kernel.org
Cc:	Juan Piernas Canovas <piernas@...ec.um.es>,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	sfaibish <sfaibish@....com>,
	kernel list <linux-kernel@...r.kernel.org>
Subject:  Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

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@....com>
   "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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/