lkml.org 
[lkml]   [2008]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 01/27] nilfs2: add document
    On Tue, Sep 16, 2008 at 05:10:41AM +0900, konishi.ryusuke@lab.ntt.co.jp wrote:
    > 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.

    Normally, compilebench has read phases that time how quickly the FS can
    read the files after a bunch of operations. The runs above didn't
    include the read phase, but in order to be fair to all the filesystems,
    compilebench figures out the native readdir order of the FS so it can
    create files in the optimal order for each fs.

    It does this by creating all the files in its datasets and using readdir
    to find out what order the FS returns. The files are all deleted
    and the real runs start.

    It is possible that bad perf in the first compilebench run is from
    cleanup or transaction commits being done after the deletions.

    -chris


    \
     
     \ /
      Last update: 2008-09-16 15:41    [W:5.308 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site