[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: fsfs and Linux filesystems

From: Kalin KOZHUHAROV <kalin_at_thinrope.net>
Date: 2005-08-29 08:16:30 CEST

Stefan Urbat wrote:
> On Sun, 28 Aug 2005, Christopher Ness wrote:
>
>> On Sun, 2005-08-28 at 11:01 +0200, Bernd Rinn wrote:
>>
>>> Since fsfs is build on top of the native filesystem without a middle
>>> layer it should be more dependent on the performance characteristics of
>>> the native filesystem than bdb.
>>>
>>> Does anyone have experience with which Linux filesystem works best with
>>> fsfs (ext3, reiserfs, XFS, ...)? Or maybe which one to avoid? Or which
>>> mount options to set in order to get good performance?
>>>
>>> Any piece of advice would be appreciated.
>
>> Therefore this article about FS suggests that ReiserFS should be the
>> best for storing many small files.
>> http://www.linux-mag.com/2002-10/jfs_01.html
>>
>> To quote the article, about 1/2 way down the page:
>> "ReiserFS is about eight to fifteen times faster than Ext2 at handling
>> files smaller than 1K."
>>
> This FS may be best in matters of performance, but is the worst at now
> regarding data safety: you should avoid ReiserFS IMHO under all
> circumstances for truely important data on truely important servers. I
> had several incidents with it in the past; it is disintegrating itself
> rather quickly under not optimal circumstances.

To give my $0.02, I'd say I have never had any problems with
reiserfs-3.6 (the stable one in 2.6.x kernels) for 2 years or so (since
2.6.0) on 20+ machines (servers, workstations, laptops), some of them
heavily stressed and/or running out of disk space. As far as performance
is concerned - reiserfs is great (the best?) untill more than say 90-95%
of disk space is used. But any fs I tried crawls at that stage, anyway.

> My advice: use xfs, because it is the best balance at now in terms of
> safety AND performance considered together. And there are no version
> differences/mismatches, there is just ONE xfs version, while ReiserFS is
> as bad as NTFS, incompatible in several versions of it (3.5, 3.6 and 4
> are all completely incompatible in one direction: you can't use ever 4
> on a 3.6 aware system (all 2.4.x and so far all 2.6.x Kernels and never
> 3.6 on 3.5 aware systems running 2.2.x kernels with Reiser patch for
> example) and you will lose performance if running an older version with
> a newer kernel).

AFAIK, Reiser4 (vs. reiserfs) is a completely different fs from the same
vendor. It has so many new features, that to speak of compatibility is
not even important. Think FAT16 and NTFS from Microsoft.
Never used anything but ext2 on a 2.2 kernel some years ago, so cannot
comment on that one.

>> That being said, even a simple revision was 1.3K in a FSFS type file
>> system (ext3) so perhaps this is not applicable. I would expect
>> revisions to be anywhere between 2K to 100K on average for text based
>> revisions. Binaries and all bets are off.
>>
>> All that is needed is some actual data tests on the different FS'. ;)
>>
>> ReiserFS publishes some of their own benchmarks:
>> http://www.namesys.com/benchmarks.html#mongo.2.6.11
>>
> They are often tweaked to make it appear better compared with others, so
> these numbers should be taken with some care.
Yup, it is a vendor bechmark anyway, but it states in the beginnig the
conditions of the test.

> For example xfs is clearly faster when deleting big files.

And a link to recent published benchmarks proving the above statement is?
IMHO, deleting is not an often used operation in subversion, but I might
be wrong.

Kalin.

-- 
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 29 08:18:33 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.