Hi, 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 e.g. #nsegments_per_clean 2 nsegments_per_clean 1 2) Re-create the partition using mkfs.nilfs2 with a smaller segment size. e.g. # 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. Regards, Ryusuke Konishi _______________________________________________ users mailing list [email protected] https://www.nilfs.org/mailman/listinfo/users
