[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[linux-lvm] Re: Oops unmounting snapshot of xfs filesystem



Stephenson, Dale wrote:

Klaus Strebel's suggestion to use 2.91.66 (kgcc) for the kernel did solve
the oops from snapshot umounting, in ordinary circumstances.  Thanks!

However, I still have similar behavior, from umounting an invalid
(filled-up) snapshot.  I took three snapshots of a single xfs logical
volume, mounted the snapshots, and ran I-O on the source until the snapshots
were invalidated.  I then umounted two of the snapshots.  I saw
xfs_force_shutdown messages in syslog for each umount, and the second umount
oopsed.

Here's the syslog entries:

<6> Feb 14 15:24:11 kernel: lvm -- giving up to snapshot /dev/volgr0/lvol0
on /dev/volgr0/lvol1: out of space <6> Feb 14 15:24:11 kernel: lvm -- giving up to snapshot /dev/volgr0/lvol0
on /dev/volgr0/lvol2: out of space <6> Feb 14 15:24:11 kernel: lvm -- giving up to snapshot /dev/volgr0/lvol0
on /dev/volgr0/lvol3: out of space <1> Feb 14 15:24:43 kernel: lvm - lvm_map: ll_rw_blk for inactive LV
/dev/volgr0/lvol1 <1> Feb 14 15:24:43 kernel: lvm - lvm_map: ll_rw_blk for inactive LV
/dev/volgr0/lvol1 <4> Feb 14 15:24:43 kernel: I/O error in filesystem ("lvm(58,1)") meta-data
dev 0x3a01 block 0xa00020 <4> Feb 14 15:24:43 kernel: ("xlog_iodone") error 5 buf count 1024 <4> Feb 14 15:24:43 kernel: xfs_force_shutdown(lvm(58,1),0x2) called from
line 939 of file xfs_log.c. Return address = 0xc01b934e <4> Feb 14 15:24:43 kernel: Log I/O Error Detected. Shutting down
filesystem: lvm(58,1) <4> Feb 14 15:24:43 kernel: Please umount the filesystem, and rectify the
problem(s) <1> Feb 14 15:24:48 kernel: lvm - lvm_map: ll_rw_blk for inactive LV
/dev/volgr0/lvol2 <1> Feb 14 15:24:48 kernel: lvm - lvm_map: ll_rw_blk for inactive LV
/dev/volgr0/lvol2 <4> Feb 14 15:24:48 kernel: I/O error in filesystem ("lvm(58,2)") meta-data
dev 0x3a02 block 0xa00020 <4> Feb 14 15:24:48 kernel: ("xlog_iodone") error 5 buf count 1024 <4> Feb 14 15:24:48 kernel: xfs_force_shutdown(lvm(58,2),0x2) called from
line 939 of file xfs_log.c. Return address = 0xc01b934e <4> Feb 14 15:24:48 kernel: Log I/O Error Detected. Shutting down
filesystem: lvm(58,2) <4> Feb 14 15:24:48 kernel: Please umount the filesystem, and rectify the
problem(s) <1> Feb 14 15:24:48 kernel: Unable to handle kernel NULL pointer dereference
at virtual address 00000020 [oops snipped, but output of ksymoops attached to message]


System details:
Celeron with 512 MB of RAM and WD 45GB harddrives.
128 MB swap, one vg consisting of a one-drive RAID 0.
Kernel 2.4.16 with 12/14/01 xfs CVS.
LVM CVS of 1/21/02 (functionally identical to 1.0.2, I believe).
LVM's linux-2.4.11-VFS-lock.patch.
xfs_fs_freeze() patch posted by Eric Sandeen.
Anselm Kruis' writable snapshot patch.

Snapshots were mounted ro,nouuid,norecovery.  The only action taken to the
snapshots was mounting.

I hope to try it soon with 2.4.17, as Adrian Head suggested.

Has anyone else run this case with xfs snapshots?

Why does umount result in I/O activity to a read-only, norecovery file
system?

Thanks,
Dale Stephenson
steph snapserver com


This is definitely odd, xlog_iodone is the I/O completion function for a log write. What
I would suspect is that xfs is not actually seeing the read only state somewhere.


I have mounted a regular filesystem with these options and set break points
in various spots during unmount which would do writes, none of them trigger.

Can you build with kdb, run the same test with a breakpoint in xfs_forced_shutdown,
and then when it trips do a backtrace for the unmount process.


Thanks

Steve








[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]