I'm looking for a technical comparison between the major file systems.
At a minimum I'd like to see a comparison between ext3, reiserfs, xfs
and jfs. In the oh so perfect world I'd like to see detailed info on all
supported file systems.
Please CC or mail me directly as I am not a subscriber to this list.
Thanks
--
Steve Glines
In theory, there's no difference between theory and practice, but in
practice there is.
http://www.linux-mag.com/2002-10/jfs_01.html
On some point it could be discussed, but it is a good starting point.
if you know italian, I will send you another article published in three part
on Linux&C (http://www.oltrelinux.com) about journaled filesystems available in
Linux kernel.
bests
Luigi
On Fri, 2 Jan 2004, Steve Glines wrote:
> Date: Fri, 02 Jan 2004 16:38:22 -0500
> From: Steve Glines <[email protected]>
> To: [email protected]
> Subject: file system technical comparisons
>
> I'm looking for a technical comparison between the major file systems.
> At a minimum I'd like to see a comparison between ext3, reiserfs, xfs
> and jfs. In the oh so perfect world I'd like to see detailed info on all
> supported file systems.
>
> Please CC or mail me directly as I am not a subscriber to this list.
>
> Thanks
> --
> Steve Glines
>
> In theory, there's no difference between theory and practice, but in
> practice there is.
>
>
> -
> 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/
>
You can read http://www.namesys.com for a description of reiser4, and
http://www.namesys.com/benchmarks.html for some benchmarks.
There are no well done independent benchmarks unfortunately.
Of my competitors, and not considering ReiserFS (about which I am not
objective), I would say that if you don't have really large files and
don't have any large directories, ext3 offers the best performance.
If you have large streaming files, look at XFS. Don't use XFS for
files smaller than 100k, as the last time I tested against it its
metadata updates tended to be slow, and that starts to matter at <100k
file sizes.
JFS has never done very well in the benchmarks I run, which is why I
tend to compare us mostly to ext3.
If you are willing to consider ReiserFS, V3 is the journaling filesystem
that has been out for the longest, and receives the least updates (we
are all working on V4), so it is the most stable. I'll let others
comment on its performance.
V4 is far higher performance than V3, but not quite fully stable yet.
Some brave people are using it though. Hopefully we will ship something
stable this month.
Hans
[email protected] wrote:
>http://www.linux-mag.com/2002-10/jfs_01.html
>
>On some point it could be discussed, but it is a good starting point.
>
>if you know italian, I will send you another article published in three part
>on Linux&C (http://www.oltrelinux.com) about journaled filesystems available in
>Linux kernel.
>
>bests
>
>Luigi
>
>On Fri, 2 Jan 2004, Steve Glines wrote:
>
>
>
>>Date: Fri, 02 Jan 2004 16:38:22 -0500
>>From: Steve Glines <[email protected]>
>>To: [email protected]
>>Subject: file system technical comparisons
>>
>>I'm looking for a technical comparison between the major file systems.
>>At a minimum I'd like to see a comparison between ext3, reiserfs, xfs
>>and jfs. In the oh so perfect world I'd like to see detailed info on all
>>supported file systems.
>>
>>Please CC or mail me directly as I am not a subscriber to this list.
>>
>>Thanks
>>--
>>Steve Glines
>>
>>In theory, there's no difference between theory and practice, but in
>>practice there is.
>>
>>
>>-
>>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/
>>
>>
>>
>
>-
>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/
>
>
>
>
--
Hans
I already gave a look to reiser4, but I have some difficoultis with dancing
tree structure.
But definitelly I was waiting for an extent based FS
as we talked about this more than one year and a half ago,
when you described me
your plans for reiser in an interview on Linux&C.
Now, will have to find some time to set up a test, possibly on a 64 bit CPU.
bests
Luigi
On Mon, 5 Jan 2004, Hans Reiser wrote:
> Date: Mon, 05 Jan 2004 14:04:58 +0300
> From: Hans Reiser <[email protected]>
> To: [email protected]
> Cc: Steve Glines <[email protected]>, [email protected]
> Subject: Re: file system technical comparisons
>
> You can read http://www.namesys.com for a description of reiser4, and
> http://www.namesys.com/benchmarks.html for some benchmarks.
>
> There are no well done independent benchmarks unfortunately.
>
> Of my competitors, and not considering ReiserFS (about which I am not
> objective), I would say that if you don't have really large files and
> don't have any large directories, ext3 offers the best performance.
>
> If you have large streaming files, look at XFS. Don't use XFS for
> files smaller than 100k, as the last time I tested against it its
> metadata updates tended to be slow, and that starts to matter at <100k
> file sizes.
>
> JFS has never done very well in the benchmarks I run, which is why I
> tend to compare us mostly to ext3.
>
> If you are willing to consider ReiserFS, V3 is the journaling filesystem
> that has been out for the longest, and receives the least updates (we
> are all working on V4), so it is the most stable. I'll let others
> comment on its performance.
>
> V4 is far higher performance than V3, but not quite fully stable yet.
> Some brave people are using it though. Hopefully we will ship something
> stable this month.
>
> Hans
>
> [email protected] wrote:
>
> >http://www.linux-mag.com/2002-10/jfs_01.html
> >
> >On some point it could be discussed, but it is a good starting point.
> >
> >if you know italian, I will send you another article published in three part
> >on Linux&C (http://www.oltrelinux.com) about journaled filesystems available in
> >Linux kernel.
> >
> >bests
> >
> >Luigi
> >
> >On Fri, 2 Jan 2004, Steve Glines wrote:
> >
> >
> >
> >>Date: Fri, 02 Jan 2004 16:38:22 -0500
> >>From: Steve Glines <[email protected]>
> >>To: [email protected]
> >>Subject: file system technical comparisons
> >>
> >>I'm looking for a technical comparison between the major file systems.
> >>At a minimum I'd like to see a comparison between ext3, reiserfs, xfs
> >>and jfs. In the oh so perfect world I'd like to see detailed info on all
> >>supported file systems.
> >>
> >>Please CC or mail me directly as I am not a subscriber to this list.
> >>
> >>Thanks
> >>--
> >>Steve Glines
> >>
> >>In theory, there's no difference between theory and practice, but in
> >>practice there is.
> >>
> >>
> >>-
> >>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/
> >>
> >>
> >>
> >
> >-
> >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/
> >
> >
> >
> >
>
>
> --
> Hans
>
>
[email protected] wrote:
>I already gave a look to reiser4, but I have some difficoultis with dancing
>tree structure.
>
>
>
Difficulties meaning that you don't think it is a good
structure/algorithm, or that you don't find the docs understandable?
--
Hans
On Mon, 5 Jan 2004 10:42:32 +0100 (CET) [email protected] wrote:
|
| http://www.linux-mag.com/2002-10/jfs_01.html
|
| On some point it could be discussed, but it is a good starting point.
|
| if you know italian, I will send you another article published in three part
| on Linux&C (http://www.oltrelinux.com) about journaled filesystems available in
| Linux kernel.
|
| bests
|
| Luigi
|
| On Fri, 2 Jan 2004, Steve Glines wrote:
|
| > Date: Fri, 02 Jan 2004 16:38:22 -0500
| > From: Steve Glines <[email protected]>
| > To: [email protected]
| > Subject: file system technical comparisons
| >
| > I'm looking for a technical comparison between the major file systems.
| > At a minimum I'd like to see a comparison between ext3, reiserfs, xfs
| > and jfs. In the oh so perfect world I'd like to see detailed info on all
| > supported file systems.
| >
| > Please CC or mail me directly as I am not a subscriber to this list.
| >
| > Thanks
| > --
| > Steve Glines
A couple of years ago I did a journaling filesystems comparison
for 2.4.x, so it's quite dated. I wouldn't pay much attention to
the performance numbers from then.
You can get some other (non-performance) comparison info by looking
at <http://developer.osdl.org/rddunlap/journal_fs/lwe-jgfs.pdf>.
--
~Randy
MOTD: Always include version info.
That there is something I am not really sure I understood.
Luigi
On Mon, 5 Jan 2004, Hans Reiser wrote:
> Date: Mon, 05 Jan 2004 20:18:26 +0300
> From: Hans Reiser <[email protected]>
> To: [email protected]
> Cc: Steve Glines <[email protected]>, [email protected]
> Subject: Re: file system technical comparisons
>
> [email protected] wrote:
>
> >I already gave a look to reiser4, but I have some difficoultis with dancing
> >tree structure.
> >
> >
> >
> Difficulties meaning that you don't think it is a good
> structure/algorithm, or that you don't find the docs understandable?
>
> --
> Hans
>
>
What would be interesting is a new comparison between reiserFS reiser4 and
latest XFS. To be onest I think ext3, with or withou HTree, obsolete, but it is
abvious if you consider its origins, while I do not speack about JFS, since
technically is interesting, but then the bench I did, more than an year ago,
were not untisiasmant, and it was buggy when in a DIR there were too many
"small" files.
Luigi
On Mon, 5 Jan 2004, Randy.Dunlap wrote:
> Date: Mon, 5 Jan 2004 09:37:45 -0800
> From: Randy.Dunlap <[email protected]>
> To: [email protected]
> Cc: [email protected], [email protected]
> Subject: Re: file system technical comparisons
>
> On Mon, 5 Jan 2004 10:42:32 +0100 (CET) [email protected] wrote:
>
> |
> | http://www.linux-mag.com/2002-10/jfs_01.html
> |
> | On some point it could be discussed, but it is a good starting point.
> |
> | if you know italian, I will send you another article published in three part
> | on Linux&C (http://www.oltrelinux.com) about journaled filesystems available in
> | Linux kernel.
> |
> | bests
> |
> | Luigi
> |
> | On Fri, 2 Jan 2004, Steve Glines wrote:
> |
> | > Date: Fri, 02 Jan 2004 16:38:22 -0500
> | > From: Steve Glines <[email protected]>
> | > To: [email protected]
> | > Subject: file system technical comparisons
> | >
> | > I'm looking for a technical comparison between the major file systems.
> | > At a minimum I'd like to see a comparison between ext3, reiserfs, xfs
> | > and jfs. In the oh so perfect world I'd like to see detailed info on all
> | > supported file systems.
> | >
> | > Please CC or mail me directly as I am not a subscriber to this list.
> | >
> | > Thanks
> | > --
> | > Steve Glines
>
> A couple of years ago I did a journaling filesystems comparison
> for 2.4.x, so it's quite dated. I wouldn't pay much attention to
> the performance numbers from then.
>
> You can get some other (non-performance) comparison info by looking
> at <http://developer.osdl.org/rddunlap/journal_fs/lwe-jgfs.pdf>.
>
> --
> ~Randy
> MOTD: Always include version info.
> -
> 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/
>
[email protected] wrote:
>That there is something I am not really sure I understood.
>
>Luigi
>
>
>
balanced trees squish things together at every modification of the
tree. Dancing trees squish things together when they get low on ram,
which is less often. this means that we can afford to squish tighter
because we do it less often.
--
Hans
[email protected] wrote:
>What would be interesting is a new comparison between reiserFS reiser4 and
>latest XFS. To be onest I think ext3, with or withou HTree, obsolete, but it is
>abvious if you consider its origins, while I do not speack about JFS, since
>technically is interesting, but then the bench I did, more than an year ago,
>were not untisiasmant, and it was buggy when in a DIR there were too many
>"small" files.
>
>Luigi
>
>
>
Actually I agree with you that JFS is architecturally much more
interesting than ext3 (though Andrew Morton's readahead code for ext* is
beautiful stuff). I haven't really looked at why JFS is slow, though
usually being slow at <100k sized files in a journaling filesystem is
due to the journaling code. The thing about performance is that the
mistakes count for 4x what the things done right count for. Chris Mason
did a lot for V3's performance compared to the competition by writing
nice journaling code for us.
htree has performance problems that are due to its architecture --- I
think this is why they don't make it on by default --- it actually slows
ext3 down substantially for average directory sizes..... you can see
that on our benchmarks page, or just by copying around some copies of
the linux kernel yourself with it on and off.
--
Hans
On Tue, Jan 06, 2004 at 05:55:24PM +0300, Hans Reiser wrote:
>
> htree has performance problems that are due to its architecture --- I
> think this is why they don't make it on by default --- it actually slows
> ext3 down substantially for average directory sizes..... you can see
> that on our benchmarks page, or just by copying around some copies of
> the linux kernel yourself with it on and off.
Actually, the reason why we didn't enable by default was more because
of conservatism; it's a new feature, and during the bug shakedown
phase, we didn't want to impact users with some of the initial memory
leaks, NFS server incompatibilities, etc., that have since been all
fixed.
Htree has performance problems for certain workloads --- specifically,
workloads that do a readdir() followed by a stat(). This is because
readdir() returns inodes in hash value order, instead of in the order
that the files were created (which generally meant increasing inode
order). Because accesses to the inode table now become random, this
adversely impacts certain workloads, such as the kernel tar and untar
benchmark.
This can be easily fixed by changing the application to sort the
inodes by inode number, or by using an LD_PRELOAD library to do the
sorting in userspace. (See attached).
Whether or not this performance issue is a problem in real life is a
different story. If you are just doing accesses in random order and
are doing lookups by name, such as in a squid cache, you won't see
this issue at all, and htree will be a huge win. However, if like
sendmail the program is running readdir() and then stat'ing all files,
then the following LD_PRELOAD library is necessary to avoid a
performance regression caused by htree returning files in hash order.
(Note that this LD_PRELOAD library will often speed up readdir/stat
workloads on non-htree filesystems as well, since in general most
inode-based filesystems are happier when you access files in inode
order, and over time, directories tend to get disordered and are no
longer in create/inode number sorted order.)
- Ted
On Tue, 6 Jan 2004, Hans Reiser wrote:
> balanced trees squish things together at every modification of the
> tree. Dancing trees squish things together when they get low on ram,
> which is less often. this means that we can afford to squish tighter
> because we do it less often.
This is generally true except some maior cases.
A SAP server, for example, is "always" low on ram, not because of oracle, but
because how the "disp+work" processes work.
Another case I am thinking is a tibco server, when processes start to fork
because of a lot of incoming messages from everywhere, and the DB really start
to write a lot of stuff (all small writes).
I am curious to make some test in those cases.
Another think I am thinking about is an MC^2 lun. If all the I/O is resolved
inside of the EMC cache, BTrees could be better than dancing trees? In fact
in this case what matters is the CPU power you are using, since you de facto
talk just with EMC cache.
I know those are strange scenarios, but those are the scenarios I am actually
working with. Since those are not typical situations, I think right now they are
ininfluent, but in the future maybe more people will have to deal with them.
Anyway untill I do not make some serious experiment mine are just
speculations.
Luigi
[email protected] wrote:
>On Tue, 6 Jan 2004, Hans Reiser wrote:
>
>
>
>>balanced trees squish things together at every modification of the
>>tree. Dancing trees squish things together when they get low on ram,
>>which is less often. this means that we can afford to squish tighter
>>because we do it less often.
>>
>>
>
>This is generally true except some maior cases.
>
>A SAP server, for example, is "always" low on ram, not because of oracle, but
>because how the "disp+work" processes work.
>
>Another case I am thinking is a tibco server, when processes start to fork
>because of a lot of incoming messages from everywhere, and the DB really start
>to write a lot of stuff (all small writes).
>
>I am curious to make some test in those cases.
>
>
even if it is always low on ram, the memory pressure signal from VM is
still less often than the tree modification because we squish in big
batches.
>Another think I am thinking about is an MC^2 lun. If all the I/O is resolved
>inside of the EMC cache, BTrees could be better than dancing trees?
>
no, dancing trees would still fit in that cache and still be more cpu
efficient
> In fact
>in this case what matters is the CPU power you are using, since you de facto
>talk just with EMC cache.
>
>I know those are strange scenarios, but those are the scenarios I am actually
>working with. Since those are not typical situations, I think right now they are
>ininfluent, but in the future maybe more people will have to deal with them.
>
>Anyway untill I do not make some serious experiment mine are just
>speculations.
>
>Luigi
>
>
>
>
>
there are flaws in the reiser4 algorithms, but the dancing tree concept
is a good one. We are currently experimentally encountering various
oddities needing fixing. For instance, if your working set is just
barely too large for ram, we have a tendency to flush too many pages out
of ram and make you wait for us to do so. this is fixable, and being
discussed now amongst us.
--
Hans
http://www.flamingspork.com/honors/
I did some (theoretical) comparisons between a number of file systems in
my Honors thesis. Notable exceptions are NTFS and JFS. Some good
reasoning behind why some designs are better than others.
On Sat, 2004-01-03 at 08:38, Steve Glines wrote:
> I'm looking for a technical comparison between the major file systems.
> At a minimum I'd like to see a comparison between ext3, reiserfs, xfs
> and jfs. In the oh so perfect world I'd like to see detailed info on all
> supported file systems.
>
> Please CC or mail me directly as I am not a subscriber to this list.
>
> Thanks