Hi, On Fri, 19 Jun 2009 09:37:06 +0200, "Dipl.-Ing. Michael Niederle" wrote: > Hi! > > > I have turned on debug in the nilfs_cleanerd config 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
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 _______________________________________________ users mailing list [email protected] https://www.nilfs.org/mailman/listinfo/users
