Hi, I tried an lssu -a /dev/... | grep -e "2009-" | grep -e "---" without receiving a result, so I suppose on my actual nilfs2 filesystems there are no in use but not dirty segments.
Bye, David Arendt > Hi David, > On Fri, 27 Mar 2009 15:20:05 +0900 (JST), Ryusuke Konishi wrote: >> Hi, >> On Fri, 27 Mar 2009 06:55:56 +0100, David Arendt <[email protected]> >> wrote: >> > Hi, >> > >> > one thing I forgot to mention, in /etc/nilfs_cleanerd.conf I changed >> > n_segments_per clean to 20 in order to clean faster when running the >> > cleaner manually. Could this have any influence ? >> >> Yes, maybe. It raises memory pressure then may induce unusual path of >> execution like cache invalidation. It may even increase the chance of >> revealing underlying problems in relocation of on-disk blocks. >> >> Decreasing cleaning_interval is safer in general. We'll try the >> condition. >> >> Regards, >> Ryusuke > > I examined the case of nsegments_per_clean = 20 and met an > inconsistent state as follows: > > # lssu -a > SEGNUM DATE TIME STAT NBLOCKS > ... > 7418 2009-03-27 18:41:33 -d- 2048 > 7419 2009-03-27 18:41:48 -d- 2048 > 7420 2009-03-27 18:42:08 -d- 2048 > 7421 2009-03-27 18:42:28 -d- 2048 > 7422 2009-03-27 18:42:48 --- 2048 > 7423 2009-03-27 18:43:03 --- 2048 > 7424 2009-03-27 18:43:23 -d- 2048 > 7425 2009-03-27 18:43:33 ad- 1166 > 7426 ---------- --:--:-- ad- 0 > 7427 ---------- --:--:-- --- 0 > ... > > Here, the segment 7422 and 7423 are in-use but not dirty. > > This is crucial because these segments will be reallocated and > overridden later. I suspect there is a bug of error handling > somewhere, and it evaporates the dirty flag and causes the crash. > > If you have a (not broken) nilfs partition made under heavy stress, > could you try ``lssu -a'' likewise ? > > I'll dig into this from now. > > Regards, > Ryusuke Konishi > _______________________________________________ users mailing list [email protected] https://www.nilfs.org/mailman/listinfo/users
