Bug Report

Bug Report

[Dipl.-Ing. Michael Niederle]

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.

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

Re: Bug Report

[Ryusuke Konishi]

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