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