Re: reiser4 status (correction)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux