Hi Nathan,
On Tue, Jun 16, 2009 at 01:58:25PM +1000, Nathan Scott wrote:
> > indra:~# xfs_db -c frag -r /dev/sdc4
> > Segmentation fault
>
> Are these filesystems mounted when running this? (mounted
> readonly?). If not, does the segfault occur if the device
> is unmounted or mounted readonly at the time xfs_db is run?
yep, they're mounted. that's why i'm using the -r option of xfs_db.
-r Open device or filename read-only. This option is required
if the filesystem is mounted. It is only necessary to
omit this flag if a command that changes data (write,
blocktrash) is to be used.
> Running xfs_db on a mounted filesystem that is being / has
> recently been modified is known to be unreliable (the kernel
> keeps a separate address space for metadata that is not
> coherent with direct block device access).
hmm. interesting, that makes a difference.
ganesh:~# umount /export/myth4
ganesh:~# xfs_db -c frag /dev/sdb2
actual 420, ideal 413, fragmentation factor 1.67%
and, predictably, it still works OK after remounting the drive:
ganesh:~# mount /export/myth4
ganesh:~# xfs_db -c frag -r /dev/sdb2
actual 420, ideal 413, fragmentation factor 1.67%
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.
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?
> If this functionality is needed for a mounted read-write fs,
> new ioctls would be needed... (and kernel code).
the reason i reported the bug was that 'xfs_db -c frag -r' worked on
these filesystems until i defragged them with xfs_fsr.
now that they're defragged, xfs_db *always* segfaults when checking frag
% on those filesystems (at least until they're unmounted and remounted).
i.e. it seems very specific to completely (or almost completely)
defragged filesystems with very few (hundreds) files on them. other
filesystems with thousands or tens of thousands of files don't cause
segfaults.
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.
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.
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
