On Tue, Jun 16, 2009 at 04:21:35PM +1000, Nathan Scott wrote: > ----- "Craig Sanders" <c...@taz.net.au> wrote: > > unfortunately, i didn't think to run xfs_db on the fs just before > > unmounting it. that would have been useful. next time i see the > > segfault (probably tonight/tomorrow morning), i'll unmount it then > > run xfs_db again to see if it goes away when unmount flushes the > > kernel metadata to disk. > > That'd be interesting.
done. indra:~# xfs_db -c frag -r /dev/sdb1 Segmentation fault indra:~# umount /dev/sdb1 indra:~# xfs_db -c frag -r /dev/sdb1 actual 451, ideal 427, fragmentation factor 5.32% indra:~# mount /dev/sdb1 indra:~# xfs_db -c frag -r /dev/sdb1 actual 451, ideal 427, fragmentation factor 5.32% so, is there any way (other than umount) to force this metadata to be flushed to disk before running xfs_db -c flag? > Running fsr visits almost every piece of metadata on the device, > then modifies as it goes, so I would expect increased probability of > hitting this problem after running fsr. that's not good - it means that defragging a disk makes it difficult/impossible/unreliable to check fragmentation levels. and, oddly enough, one of the most likely things people will want to do after defragging a filesystem is to check the current frag factor...and, more likely than not, on a fs with stuff more important than mythtv video recordings that can't just be unmounted at whim. BTW, for my own interest's sake, i'll leave two of the partitions alone for a few days (i.e. not run xfs_fsr on them) and see if they xfs_db -c frag still segfaults on them. craig -- craig sanders <c...@taz.net.au> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
