[NILFS users] nilfs_cleanerd some questions
ryusuke at osrg.net
Fri Jan 30 18:40:34 JST 2009
On Sat, 24 Jan 2009 18:11:14 +0000, tom wrote:
> I'm using nilfs2 on a debian (lenny machine) using kernel 2.6.26-1-686
> and nilfs version 2.0.6. Currently I have a 250 Gb single partition
> drive connected via USB2, which I have formatted for nilfs2. I have
> noticed that when extracting a large archive onto the the file system
> that it seems to "burst", that is, it will extract for 5 seconds then
> halt for 1 and then repeat this cycle faithfully for the duration.
> If I switch (kill) off the GC then the "bursting" effect disappears. I
> can remove checkpoints more efficiently using rmcp, however am I right
> in thinking that the GC does more than just remove checkpoints ?
Yes, only GC can reclaim disk space; rmcp does not make free space.
> Is the behaviour that I am witnessing typical of the nilfs GC or is
> being highlighted because I am using usb instead of directly attached
> ide / sata ?
I don't know why that happens, but a likely cause is bulky reads of
blocks during GC.
In that case, the following workarounds may make a difference.
1) Decrease value of `nsegments_per_clean' in /etc/nilfs_cleanerd.conf
2) Re-create the partition using mkfs.nilfs2 with a smaller segment size.
# mkfs -t nilfs2 -B 1024 /dev/sdxx
(This halves the number of blocks per segment)
> I'm hoping to apply nilfs in production environment for our print unit
> at work because they would like self service recovery and because they
> have large amounts of graphical data that is updated daily but could
> only be safely backed up using a snaphot technology.
> However I am concerned that any large file / archive extracts onto a
> nilfs file system with the GC switched on would impede efficiency.
> It is safe to say that I wont be using USB attached storage in the
> production environment, but I thought it might be worth mentioning my
> findings as the behaviour may still be present in a very muted form on
> IDE / SATA based storage devices.
Thanks for reporting.
I feel, the current GC is indeed immature and needs more love
especially for production use.
> I guess I could run GC at off peak times as a workaround, but would it
> ever catch up ?
Not guaranteed. The speed of the GC is static unless you change
nilfs_cleanerd.conf and send a HUP signal to the GC daemon.
At least the speed should be adjusted adaptively, but not done yet.
More information about the users