System Lockup while testing nilfs
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): mailman.1.1245380401.15040.users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
Hi!
Quoted 7 lines
I have turned on debug in the
nilfs_cleanerdconfig file and I am capturing the log to a separate location. The lockup seems to occur right after a "2 segments selected to be cleaned" message was sent.gentoo distribution
2.6.30 kernel x86
nilfs-utils 2.0.12
This looks very much the same problem I encountered! It seems that under some circumstances the GC daemon issues too many read/write requests.
@Ryusuke Konishi: The last crash occured with default GC settings.
Greetings, Michael
Hi,
Quoted 10 lines · Dipl.-Ing. Michael Niederle
Hi!
Quoted 7 lines
I have turned on debug in the
nilfs_cleanerdconfig file and I am capturing the log to a separate location. The lockup seems to occur right after a "2 segments selected to be cleaned" message was sent.gentoo distribution
2.6.30 kernel x86
nilfs-utils 2.0.12
Quoted 6 lines
This looks very much the same problem I encountered! It seems that under some circumstances the GC daemon issues too many read/write requests.
@Ryusuke Konishi: The last crash occured with default GC settings.
Greetings, Michael
By default, GC reads and writes 2 segments per 5 seconds.
1 segment = 8MB (by default)
So, at maximum, it causes roughly 3.2MB read + 3.2MB write per second.
If all blocks in the segments were live, GC will copy all of them into new logs; that is 6.4MB/s I/O at worst.
If dead blocks occupies 50% of segments, the I/O load is estimated to be 3.2MB/sec since the number of copy blocks drops by half.
Under the circumstance where many snapshots exist or the protection period is set long, the rate of the must-copy-blocks can be very high.
Are you onto something?
Essentially, GC should be designed to minimize load in adapting to situation. Unfortunately, the current GC is not intelligent at all. It cannot
- stop intelligently
- resume operation intelligently
- balance reclamation speed, nor
- select target segments so that the I/O load gets minimized.
Much work to do.
Regards,
Ryusuke Konishi