Linux NILFS development
 help / color / mirror / Atom feed
From: "Ingo Glöckner" <iglockner-S0/GAf8tV78@public.gmane.org>
To: users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
Subject: Questions regarding use of nilfs2 on SSDs
Date: Sat, 28 Mar 2009 21:55:54 +0100	[thread overview]
Message-ID: <49CE8EDA.8070304@web.de> (raw)

Hello,

first of all thank you very much for contributing
this great file system, nilfs2!
I would like to use nilfs2 on an SSD but there
are some open questions, hopefully you can help
me clearing these issues.

- I have read somewhere
> http://www.ocztechnologyforum.com/forum/showpost.php?p=361424&postcount=10

  that using nilfs2 as the rootfs generates enormous I/O traffic
  (up to 45 GB write in 1-2 days!) If this is true, then it will
  eventually translate into reduced lifetime for SSDs.
  Can you confirm that the segment management of nilfs2
  is so write-heavy on the drive?
  If so, are there ways to avoid this?

- The standard segment size of nilfs2 appears to be 8MB.
  This compares to an erase block size of the SSD of
  (say) 512 KB. I wonder if reducing the segment size
  of nilfs to a smaller value (i.e., closer to the
  erase block size of the SSD) will help to
  keep the number of erased blocks/day small
  (this will benefit the lifetime of the drive)
  or if there is no such connection.
  In any case, what is the useful range for segment
  sizes? If I reduce the segment size, will I get
  a performance penalty?

- nilfs_cleanerd.conf specifies the following default values,

# The maximum number of segments to be cleaned at a time.
nsegments_per_clean     2

# Cleaning interval in second.
cleaning_interval       5

Do I interpret this correctly as stating that only 2 segments
(i.e. 16MB) can be cleaned in 5 seconds?
What negative effects will I get if I increase the number
of segments that can be cleaned at a time?

Thanks in advance for your help!
Cheers, Ingo Glöckner

             reply	other threads:[~2009-03-28 20:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-28 20:55 Ingo Glöckner [this message]
     [not found] ` <49CE8EDA.8070304-S0/GAf8tV78@public.gmane.org>
2009-03-29  6:17   ` Questions regarding use of nilfs2 on SSDs Ryusuke Konishi
     [not found]     ` <20090329.151750.64733928.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-03-29 13:30       ` Ingo Glöckner

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=49CE8EDA.8070304@web.de \
    --to=iglockner-s0/gaf8tv78@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