Two XFS involving stack traces from Debian's 2.6.26-2-amd64
Stuart Rowan
strr-debian at decisionsoft.co.uk
Thu Oct 1 02:34:10 CDT 2009
Hi,
I suspect the list will not be overly interested in these due to it
being triggered on a non-cutting edge, vendor kernel but I'll post them
anyway -- just in case there's an obvious "Debian should take patch-X"
to fix this issue in the next Lenny errata kernel.
At the time of oops, an lvm snapshot of the XFS home directory is
mounted for use by the backup scripts:
mkdir -p /tmp/$from; /sbin/lvcreate -s -L 20G -n snap-shot $from &&
mount -o nouuid,ro /dev/$vgroup/snap-shot /tmp/$from
(previously this called xfs_freeze -f / -u too but now lvcreate -s does
this itself)
When the rsync has finished the following commands are run:
umount /tmp/$from ; /sbin/lvremove -f /dev/$vgroup/snap-shot ; rmdir
/tmp/$from
The umount failed and now we have a stuck mount of the snapshot. I know
a reboot will fix the issue but it's both an annoying and infrequent
problem.
Cheers,
Stu.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gpf.txt
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20091001/308fc86c/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: umount-oops.txt
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20091001/308fc86c/attachment-0001.txt>
More information about the xfs
mailing list