linux-kernel - Re: reiser4 status (correction)

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: <1153514509.6659.41.camel@ipso.snappymail.ca>
Date:	Fri, 21 Jul 2006 13:41:48 -0700
From:	Mike Benoit <ipso@...ppymail.ca>
To:	Hans Reiser <reiser@...esys.com>
Cc:	David Masover <ninja@...phack.com>, reiserfs-list@...esys.com,
	LKML <linux-kernel@...r.kernel.org>,
	Alexander Zarochentcev <zam@...esys.com>,
	vs <vs@...bsh.namesys.com>
Subject: Re: reiser4 status (correction)

On Fri, 2006-07-21 at 02:44 -0600, Hans Reiser wrote:
> fix fsync performance (est. 1 week of time to make post-commit writes
> asynchronous, maybe 3 weeks to create fixed-reserve for write twice
> blocks, and make all fsync blocks write twice)
> 
> write repacker (12 weeks).
> 
> I am not sure that putting the repacker after fsync is the right choice....
> 

Tuning fsync will fix the last wart on Reiser4 as far as benchmarks are
concerned won't it? Right now Reiser4 looks excellent on the benchmarks
that don't use fsync often (mongo?), but last I recall the fsync
performance was so poor it overshadows the rest of the performance. It
would also probably be more useful to a much wider audience, especially
if Namesys decides to charge for the repacker.

ReiserV3 is used on a lot of mail and squid proxy servers that deal with
many small files, and these work loads usually call fsync often. My
guess is that ReiserV3 users are the most likely to migrate to Reiser4,
because they already know the benefits of using a "Reiser" file system.
But neglecting fsync performance will just put a sour taste in their
mouth. 

On top of that, I don't see how a repacker would help these work loads
much as the files usually have a high churn rate. Packing them would
probably be a net loss as the files would just be deleted in 24hrs and
replaced by new ones.

Very few people will (or should) disable fsync as David suggests, I
don't see that as a solution at all, even if it is temporary.

-- 
Mike Benoit <ipso@...ppymail.ca>

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)