linux-kernel - Re: Solaris ZFS on Linux [Was: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

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: <44CEAEF4.9070100@slaphack.com>
Date:	Mon, 31 Jul 2006 20:31:32 -0500
From:	David Masover <ninja@...phack.com>
To:	Nate Diller <nate.diller@...il.com>,
	David Lang <dlang@...italinsight.com>,
	Adrian Ulrich <reiser4@...nkenlights.ch>,
	"Horst H. von Brand" <vonbrand@....utfsm.cl>, ipso@...ppymail.ca,
	reiser@...esys.com, lkml@...productions.com, jeff@...zik.org,
	tytso@....edu, linux-kernel@...r.kernel.org,
	reiserfs-list@...esys.com
Subject: Re: Solaris ZFS on Linux [Was: Re: the " 'official' point of view"
 expressed by kernelnewbies.org regarding reiser4 inclusion]

Matthias Andree wrote:
> On Mon, 31 Jul 2006, Nate Diller wrote:
> 
>> this is only a limitation for filesystems which do in-place data and
>> metadata updates.  this is why i mentioned the similarities to log
>> file systems (see rosenblum and ousterhout, 1991).  they observed an
>> order-of-magnitude increase in performance for such workloads on their
>> system.
> 
> It's well known that transactions that would thrash on UFS or ext2fs may
> have quieter access patterns with shorter strokes can benefit from
> logging, data journaling, whatever else turns seeks into serial writes.
> And then, the other question with wandering logs (to avoid double
> writes) and such, you start wondering how much fragmentation you get as
> the price to pay for avoiding seeks and double writes at the same time.

So you use a repacker.  Nice thing about a repacker is, everyone has 
downtime.  Better to plan to be a little sluggish when you'll have 
1/10th or 1/50th of the users than be MUCH slower all the time.

You're right, though, to ask the question:

> TANSTAAFL, or how long the system can sustain such access patterns,
> particularly if it gets under memory pressure and must move.

Anyone care to run some very long benchmarks?

> Even with
> lazy allocation and other optimizations, I question the validity of
> 3000/s or faster transaction frequencies. Even the 500 on ext3 are
> suspect, particularly with 7200/min (s)ATA crap. This sounds pretty much
> like the drive doing its best to shuffle blocks around in its 8 MB cache
> and lazily writing back.

Oh, I'm curious -- do hard drives ever carry enough battery/capacitance 
to cover their caches?  It doesn't seem like it would be that 
hard/expensive, and if it is done that way, then I think it's valid to 
leave them on.  You could just say that other filesystems aren't taking 
as much advantage of newer drive features as Reiser :P

Anyway, remember that the primary tool of science is not logic.  Logic 
is the primary tool of philosophy.  The primary tool of science is 
observation.

Sorry, the only machines I could really run this on are about to be in 
remote only mode for a couple weeks.  I'm hesitant to hit them too hard.
-
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/