lkml.org 
[lkml]   [2006]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: reiser4 status (correction)
Mike Benoit wrote:

> 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.

If Namesys does decide to charge for the repacker, I'll have to consider
whether it's worth it to pay for it or to use XFS instead. Reiser4
tends to become much more fragmented than most other Linux FSes --
purely subjective, but probably true.

> 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.
[...]
> But neglecting fsync performance will just put a sour taste in their
> mouth.

So will neglecting fragmentation, only worse. At least fsync is slow up
front. Fragmentation will be slow much farther in, when the mailserver
has already been through one painful upgrade. Charging for the repacker
just makes it worse.

> 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.

Depends. Some will, some won't. My IMAP server does have a lot of
churning, but there's also the logs (which stay for at least a month or
two before they rotate out), and since it's IMAP, I do leave quite a lot
of files alone.

v3 is also used on a lot of web servers, at least where I used to work
-- some areas will be changing quite a lot, and some areas not at all.
Changing a lot means fragmentation will happen, not changing at all
means repacking will help.

These issues may be helped by partitioning, if you know how you're going
to split things up. But then, how do you partition in the middle of a
squid server? A lot of people visit the same sites every day, checking
for news, but that means plenty of logos, scripts, and other things
won't change -- but plenty of news articles will change every couple hours.

> 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.

I guess the temporary solution is to incur a pretty big performance hit.
But it comes back to, which is more of a performance problem, fsync or
fragmentation?

And I really would like to hear a good counter-argument to the one I've
given for disabling fsync. But even if we assume fsync must stay, do we
have any benchmarks on fragmentation versus fsync?

But maybe it's best to stop debating, since both will be done
eventually, right?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-07-25 21:35    [W:0.058 / U:1.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site