From: Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org>
To: crmafra-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
Subject: Re: NILFS2 on an Intel X25-M SSD
Date: Sun, 03 Jan 2010 02:24:25 +0900 (JST) [thread overview]
Message-ID: <20100103.022425.52166650.ryusuke@osrg.net> (raw)
In-Reply-To: <4B3C7326.4010002-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 31 Dec 2009 10:47:18 +0100, "Carlos R. Mafra" wrote:
> Am 30.12.2009 19:46, schrieb Ryusuke Konishi:
> > On Tue, 29 Dec 2009 20:48:47 +0100, "Carlos R. Mafra" wrote:
> >> Is there any specific tweak in NILFS2 to use with an SSD? Would you
> >> reccomend using NILFS2 on a SSD right now?
> >>
> >> Is the issue mentioned here
> >>
> >> https://www.nilfs.org/pipermail/users/2009-March/000514.html
> >>
> >> about excessive writing in the GC already fixed?
> >> That is the most pressing fear I have about NILFS2 for the SSD.
> >
> > Not yet, sorry. I'm working on some performance optimization for high
> > speed drives espacially for SSD. Revising GC is another priority, but
> > it would need some time.
> >
> > The massive I/O by the current garbage collector may shorten the life
> > of SSD. So, I don't recommend yet.
>
> Hmm, then I won't use NILFS2 on the SSD for now.
>
> I am testing it in an external HD for the last two days to get a feeling,
> and so far everything looks good and stable. It is a pity that the
> massive I/O problem kind of prevents putting it on the SSD.
Definitely yes.
NILFS2 is pretty stable, but this issue is spoiling the goodness
especially for netbook users.
> Naively I would think that the GC will always create some I/O that
> other filesystems don't have, by its very definition. Can you
> quantify by how much the current GC is writing in excess and what would
> be the acceptable numbers?
The overhead is roughly measured as the number of copied (moved)
blocks per reclaimed segment. The following patch will print the
ratio (number of copied blocks / cleaned blocks) into syslog.
A NILFS2 root of my laptop constantly marks 70~99%.
This is because the current GC regularly frees segments from older
ones without any attempt to minimize the above ratio; it doesn't
select target segments that way, and it doesn't delay reclamation even
when the partition has enough free space.
I don't know how much is acceptable, but at least, I think the GC
frequency should be suppressed to 0 while the partition has enough
free space, and the selection algorithm should be improved to give
priority to free segments containing less in-use blocks.
Regards,
Ryusuke Konishi
--
diff --git a/sbin/cleanerd/cleanerd.c b/sbin/cleanerd/cleanerd.c
index f36dfce..6a35f15 100644
--- a/sbin/cleanerd/cleanerd.c
+++ b/sbin/cleanerd/cleanerd.c
@@ -921,6 +921,8 @@ static ssize_t nilfs_cleanerd_clean_segments(struct nilfs_cleanerd *cleanerd,
{
struct nilfs_vector *vdescv, *bdescv, *periodv, *vblocknrv;
ssize_t n, ret = -1;
+ size_t nr_vblocks, nr_pblocks, nr_live_vblocks, nr_live_pblocks;
+ size_t nr_blocks, nr_live_blocks;
int i;
if (nsegs == 0)
@@ -953,10 +955,14 @@ static ssize_t nilfs_cleanerd_clean_segments(struct nilfs_cleanerd *cleanerd,
if (ret < 0)
goto out_lock;
+ nr_vblocks = nilfs_vector_get_size(vdescv);
+
ret = nilfs_cleanerd_toss_vdescs(cleanerd, vdescv, periodv, vblocknrv);
if (ret < 0)
goto out_lock;
+ nr_live_vblocks = nilfs_vector_get_size(vdescv);
+
nilfs_vector_sort(vdescv, nilfs_comp_vdesc_blocknr);
nilfs_cleanerd_unify_period(cleanerd, periodv);
@@ -964,10 +970,17 @@ static ssize_t nilfs_cleanerd_clean_segments(struct nilfs_cleanerd *cleanerd,
if (ret < 0)
goto out_lock;
+ nr_pblocks = nilfs_vector_get_size(bdescv);
+
ret = nilfs_cleanerd_toss_bdescs(cleanerd, bdescv);
if (ret < 0)
goto out_lock;
+ nr_live_pblocks = nilfs_vector_get_size(bdescv);
+
+ nr_blocks = nr_vblocks + nr_pblocks;
+ nr_live_blocks = nr_live_vblocks + nr_live_pblocks;
+
ret = nilfs_clean_segments(cleanerd->c_nilfs,
nilfs_vector_get_data(vdescv),
nilfs_vector_get_size(vdescv),
@@ -983,8 +996,13 @@ static ssize_t nilfs_cleanerd_clean_segments(struct nilfs_cleanerd *cleanerd,
} else {
if (n > 0) {
for (i = 0; i < n; i++)
- syslog(LOG_DEBUG, "segment %llu cleaned",
+ syslog(LOG_INFO, "segment %llu cleaned",
(unsigned long long)segnums[i]);
+ syslog(LOG_INFO,
+ "copied blocks / total blocks : %zu / %zu "
+ "(%3.1f%%)",
+ nr_live_blocks, nr_blocks,
+ nr_live_blocks * 100.0 / nr_blocks);
} else {
syslog(LOG_DEBUG, "no segments cleaned");
}
next prev parent reply other threads:[~2010-01-02 17:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4B3A5D1F.9010002@gmail.com>
[not found] ` <4B3A5D1F.9010002-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-12-30 18:46 ` NILFS2 on an Intel X25-M SSD Ryusuke Konishi
[not found] ` <20091231.034629.85391956.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-12-31 9:47 ` Carlos R. Mafra
[not found] ` <4B3C7326.4010002-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-01-02 17:24 ` Ryusuke Konishi [this message]
[not found] ` <20100103.022425.52166650.ryusuke-sG5X7nlA6pw@public.gmane.org>
2010-01-02 20:44 ` Carlos R. Mafra
[not found] ` <20100102204417.GA6877-8NNKxJcwqxqHjx4iBuKRcg@public.gmane.org>
2010-01-03 12:39 ` Ryusuke Konishi
2010-01-02 20:00 admin-/LHdS3kC8BfYtjvyW6yDsg
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=20100103.022425.52166650.ryusuke@osrg.net \
--to=ryusuke-sg5x7nla6pw@public.gmane.org \
--cc=crmafra-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-nilfs-u79uwXL29TY76Z2rM5mHXA@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.