All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.