Linux NILFS development
 help / color / mirror / Atom feed
From: Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org>
To: NILFS Users mailing list <users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org>
Subject: Re: Using nilfs to increase performance of NAND/SSD flash devices.
Date: Tue, 05 Feb 2008 21:59:08 +0900	[thread overview]
Message-ID: <1202216348.7401.63.camel@localhost.localdomain> (raw)
In-Reply-To: <30c6373b0802011231t75a8a00djab3c82b4de3fa928-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hi Kevin,

On Fri, 2008-02-01 at 12:31 -0800, Kevin Burton wrote:
> 
> Hey guys.
> 
> I'm playing with nilfs2 on an Mtron SSD 32G NAND Flash SATA drive.

We're also preparing for the test on SSD!

> NAND is GREAT for random reads but horrible for random writes.
> 
> A log filesystem fixes this problem because when the disk does random
> writes it
> will just read the block from the previous erase block and wrote a new
> block
> with the data to the end of the drive, thereby simulating sequential
> writes.
> 
> I tested this theory by comparing nilfs2 to XFS on the mtron with a
> sysbenchm
> random write to test.  Sure enough nilfs2 beat out XFS by 8.5x and
> wrote at
> about 50MB/s which is amazingly impressive.

Yes, this is a well-known effect and an age-old application of lfs.
Though the primary motivation of NILFS was not in this use,
I think it's one of interesting matters when considering the recent
rise of the NAND flash devices and their future trends especially
for their increase in the capacity. 

As Chris pointed out, we should once compare lfs-like filesystems
justly because we have some choices for this purpose.

> The problem is that with I used the sysbench OLTP benchmark it was
> only about
> 10% faster than an HDD running XFS.
> 
> Not too impressive.
> 
> The OLTP benchmark simulates a MySQL box doing lots of random DELETE,
> UPDATE,
> and INSERT commands so you end up seeing lots or random writes to the
> disk.

Umm, I don't know the reason why the OLTP benchmark doesn't show 
the expected result.  Does it invoke many synchronous writes? 

NILFS incurs overheads for HDD read, so I'm also concerned with read
performance of SSD.


> Is it possible to disable checkpointing to test my theory?  I'm just
> about to
> dive into the source to test this out but I wanted to post here first
> to get
> your thoughts.

No, I think we cannot disable checkpointing.
But if we have good idea to test your theory, we'll reply later.

Regards,
-- 
Ryusuke Konishi
NILFS team NTT
http://www.nilfs.org/

      parent reply	other threads:[~2008-02-05 12:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-01 20:31 Using nilfs to increase performance of NAND/SSD flash devices Kevin Burton
     [not found] ` <30c6373b0802011231t75a8a00djab3c82b4de3fa928-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-04 10:00   ` Chris Samuel
2008-02-05 12:59   ` Ryusuke Konishi [this message]

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=1202216348.7401.63.camel@localhost.localdomain \
    --to=ryusuke-sg5x7nla6pw@public.gmane.org \
    --cc=users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org \
    /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