Hi, On Thu, 11 Jun 2009 19:51:23 +0200, "Dipl.-Ing. Michael Niederle" wrote: > Hi! > > Today I installed SIMPLUX on a freshly formatted 30GB partition on a > pen drive. I updated the whole system, compiled and installed the > final version of the 2.6.30 kernel. I did not apply any further > nilfs-patches. Everything worked fine. Then (using the new kernel) I > deleted several GB of old data. The garbage collection worked really > slow, so I changed the settings in nilfs_cleanerd.conf as follows: > > protection_period 900 > selection_policy timestamp > nsegments_per_clean 10 > cleaning_interval 5 > use_mmap > log_priority info > > Then I restarted the cleaner daemon and was happy to see now much > more activity on the pen-drive. The garbage collection claimed back > MB after MB. I thought it would take some time for the garbage > collection to complete and left the room. > > When I returned the machine was completely crashed (black screen - maybe due > to the screen saver). I could only reboot it via "ctrl-alt-sysrqst USB". > > There was no background job during the time of the crash - just an idling > X-desktop (iceWM - so only very few running daemons). > > The next reboot took half an hour! Here an excerpt from the kernel > log: > > [ 2.407501] usb-storage: device scan complete > [ 2.456443] sd 2:0:0:1: [sdd] Attached SCSI removable disk > [ 1759.409004] segctord starting. Construction interval = 5 seconds, CP > frequenc > [ 1759.421950] NILFS warning: mounting unchecked fs > [ 1759.456071] NILFS: recovery complete. > > It seems nilfs read the whole partition - byte for byte. This would take > approximately the time spent. Wouldn't it suffice to read all segment headers > to recover? The pen drive can handle more than 2000 reads per second.
It's obviously abnormal. Nilfs stores a pointer to the latest log in superblocks. If power failure occurs, nilfs tries to recover newer logs by scanning them from the pointed log. So, your problem seems that neither superblock has been written back to your pendrive for very long period. I think the heavy GC load prevented the writeback. In general, decreasing cleaning_interval is safer than increasing the nsegments_per_clean to accelerate garbage collection. Okay, I'll consider enforcing writeback of superblocks to avoid long duration recovery on mount. Thank you for reporting this issue. > Before it (presumably) crashed the system the cleaner daemon had done a > nice job - freeing several GB of unused space (but not yet completed the > garbage collection). > > Greetings, Michael Regards, Ryusuke Konishi _______________________________________________ users mailing list [email protected] https://www.nilfs.org/mailman/listinfo/users
