----- "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. > however, the segfaults listed in my previous message were from xfs_db > being run this morning. the xfs_fsr jobs were run yesterday. > > what does "recently modified" mean? seconds? minutes? hours? Yes, all of the above. The buffers cached for the block device can remain in-core and inconsistent with whats on disk for a long time (the block device thinks the buffers are clean, so doesn't attempt to re-read them until they've been tossed through normal VM page reclaim algorithms). > the other point here is that segfaulting didn't happen while they > were > still reporting significant fragmentation - 10%, 60%, 90% whatever. > it, > only seems to happen when fragmentation is zero or very close to > zero. 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. > in short - what you're saying about metadata in kernel memory being > different to metadata on disk may contribute to this, but i don't > think it's the whole story or even the source of the problem. The acid test will be interesting to see if the problem ever occurs on readonly mounted, or unmounted filesystems. If it does, it'd be good to capture an xfs_metadump and send that to the xfs developers at x...@oss.sgi.com & they will take it from there. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
