The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: konishi.ryusuke@lab.ntt.co.jp
To: pavel@suse.cz
Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/27] nilfs2: add document
Date: Tue, 16 Sep 2008 05:10:41 +0900 (JST)	[thread overview]
Message-ID: <20080916.051041.110880811.ryusuke@osrg.net> (raw)
In-Reply-To: <20080915095427.GA1861@elf.ucw.cz>

Hi!

On Mon, 15 Sep 2008 11:54:27 +0200, Pavel Machek wrote:
> Hi!
> 
> > +NILFS2 is a log-structured file system (LFS) supporting continuous
> > +snapshotting.  In addition to versioning capability of the entire file
> > +system, users can even restore files mistakenly overwritten or
> 
> Hmm, undelete done right. Just one question... how slow/fast is it
> compared to conventional filesystems (ext3?)?
> 								Pavel

After my first submission, Szabolcs Szakacsits showed benchmark
results using compilebench.

On Thu, 21 Aug 2008 00:25:55 +0300 (MET DST)
Szabolcs Szakacsits <szaka@ntfs-3g.org> wrote:
> I ran compilebench on kernel 2.6.26 with freshly formatted volumes.
> The behavior of NILFS2 was interesting.
>
> Its peformance rapidly degrades to the lowest ever measured level
> (< 1 MB/s) but after a while it recovers and gives consistent numbers.
> However it's still very far from the current unstable btrfs performance.
> The results are reproducible.
>
>                     MB/s    Runtime (s)
>                    -----    -----------
>   btrfs unstable   17.09        572
>   ext3             13.24        877
>   btrfs 0.16       12.33        793
>   nilfs2 2nd+ runs 11.29        674
>   ntfs-3g           8.55        865
>   reiserfs          8.38        966
>   nilfs2 1st run    4.95       3800
>   xfs               1.88       3901

Accordint to his measurement, NILFS2 showed a very low performance
on the first measument, and it recovered after a while.

I still don't know the reason why NILFS2 shows such behaviour, and
I'm thinking to follow the benchmark.

A little while ago, I tried another benchmark on the kernel 2.6.27-rc6.
The iozone benchmark.  The result was as follows:

 Throughput in MB/s (buffer size = 8B, file size = 500MB)
      <write> <rewrite> <read> <reread> <rand-read> <rand-write>
 ext3    44.918  46.691  56.541  56.505  1.562   5.716
 nilfs2  56.076  43.703  41.364  41.356  1.231   37.650
 
 Throughput in MB/s (buffer size = 64KB, file size = 500MB)
        <write> <rewrite> <read> <reread> <rand-read> <rand-write>
 ext3     45.369  46.438  56.542  56.457 11.025  36.300
 nilfs2   56.119  43.630  41.330  41.498  8.572  37.671

(Here I used -e and -U option to measure true disk read performance
 not cache read performance)

As often said for LFS, NILFS2 showed high random write performance
for small writes, but the read throughput was lower.  It was about
-27% lower than ext3.

For sequential write, first write was good, but overwrite was slower
because it involves read of existing meta data.


Cheers,
Ryusuke

  reply	other threads:[~2008-09-15 20:11 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-14 19:07 [PATCH 0/27] nilfs2: continuous snapshotting file system Ryusuke Konishi
2008-09-14 19:07 ` [PATCH 01/27] nilfs2: add document Ryusuke Konishi
2008-09-14 19:07   ` [PATCH 02/27] nilfs2: disk format and userland interface Ryusuke Konishi
2008-09-14 19:08     ` [PATCH 03/27] nilfs2: add inode and other major structures Ryusuke Konishi
2008-09-14 19:08       ` [PATCH 04/27] nilfs2: integrated block mapping Ryusuke Konishi
2008-09-14 19:08         ` [PATCH 05/27] nilfs2: B-tree based " Ryusuke Konishi
2008-09-14 19:08           ` [PATCH 06/27] nilfs2: direct " Ryusuke Konishi
2008-09-14 19:08             ` [PATCH 07/27] nilfs2: B-tree node cache Ryusuke Konishi
2008-09-14 19:08               ` [PATCH 08/27] nilfs2: buffer and page operations Ryusuke Konishi
2008-09-14 19:08                 ` [PATCH 09/27] nilfs2: meta data file Ryusuke Konishi
2008-09-14 19:08                   ` [PATCH 10/27] nilfs2: persistent object allocator Ryusuke Konishi
2008-09-14 19:08                     ` [PATCH 11/27] nilfs2: disk address translator Ryusuke Konishi
2008-09-14 19:08                       ` [PATCH 12/27] nilfs2: inode map file Ryusuke Konishi
2008-09-14 19:08                         ` [PATCH 13/27] nilfs2: checkpoint file Ryusuke Konishi
2008-09-14 19:08                           ` [PATCH 14/27] nilfs2: segment usage file Ryusuke Konishi
2008-09-14 19:08                             ` [PATCH 15/27] nilfs2: inode operations Ryusuke Konishi
2008-09-14 19:08                               ` [PATCH 16/27] nilfs2: file operations Ryusuke Konishi
2008-09-14 19:08                                 ` [PATCH 17/27] nilfs2: directory entry operations Ryusuke Konishi
2008-09-14 19:08                                   ` [PATCH 18/27] nilfs2: pathname operations Ryusuke Konishi
2008-09-14 19:08                                     ` [PATCH 19/27] nilfs2: operations for the_nilfs core object Ryusuke Konishi
2008-09-14 19:08                                       ` [PATCH 20/27] nilfs2: super block operations Ryusuke Konishi
2008-09-14 19:08                                         ` [PATCH 21/27] nilfs2: segment buffer Ryusuke Konishi
2008-09-14 19:08                                           ` [PATCH 22/27] nilfs2: segment constructor Ryusuke Konishi
2008-09-14 19:08                                             ` [PATCH 23/27] nilfs2: recovery functions Ryusuke Konishi
2008-09-14 19:08                                               ` [PATCH 24/27] nilfs2: another dat for garbage collection Ryusuke Konishi
2008-09-14 19:08                                                 ` [PATCH 25/27] nilfs2: block cache " Ryusuke Konishi
2008-09-14 19:08                                                   ` [PATCH 26/27] nilfs2: ioctl operations Ryusuke Konishi
2008-09-14 19:08                                                     ` [PATCH 27/27] nilfs2: update makefile and Kconfig Ryusuke Konishi
2008-09-17 14:41                                                   ` [PATCH 25/27] nilfs2: block cache for garbage collection Jörn Engel
2008-09-17 19:09                                                     ` Ryusuke Konishi
2008-09-17 22:49                                                       ` Jörn Engel
2008-09-20 10:43                                                         ` Ryusuke Konishi
2008-09-20 11:04                                                           ` Jörn Engel
2008-09-15 18:20                                     ` [PATCH 18/27] nilfs2: pathname operations Pekka Enberg
2008-09-16  5:31                                       ` konishi.ryusuke
2008-09-17 14:31     ` [PATCH 02/27] nilfs2: disk format and userland interface Jörn Engel
2008-09-17 15:51       ` Ryusuke Konishi
2008-09-15  9:54   ` [PATCH 01/27] nilfs2: add document Pavel Machek
2008-09-15 20:10     ` konishi.ryusuke [this message]
2008-09-16 13:38       ` Chris Mason
2008-09-17 14:54   ` Jörn Engel
2008-09-17 17:52     ` Ryusuke Konishi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080916.051041.110880811.ryusuke@osrg.net \
    --to=konishi.ryusuke@lab.ntt.co.jp \
    --cc=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox