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 > -----Original Message----- > From: Klaus Strebel [mailto:klaus.strebel@eigner.com] > Sent: Monday, February 11, 2002 2:46 AM > To: Stephenson, Dale > Cc: 'linux-xfs@oss.sgi.com'; 'linux-lvm@sistina.com' > Subject: Re: Oops unmounting snapshot of xfs filesystem > > > Stephenson, Dale wrote: > > I have been running into an oops when umounting the > snapshot of an xfs > > filesystem, or following the umount. For instance, a > umount followed by an > > lvremove will oops in the lvremove, while a > mount/umount/mount/umount > > sequence will oops on the second or third umount. > > > > What does seem consistent is the error message logged on > each umount. Here > > are the messages from a mount/umount sequence: > > > > <4> Feb 7 11:20:00 kernel: Mounting filesystem "lvm(58,1)" > in no-recovery > > mode. Filesystem will be inconsistent. > > <2> Feb 7 11:20:02 kernel: lvm - lvm_map: ll_rw_blk write > for readonly LV > > /dev/volgr0/lvol1 > > <2> Feb 7 11:20:02 kernel: lvm - lvm_map: ll_rw_blk write > for readonly LV > > /dev/volgr0/lvol1 > > <4> Feb 7 11:20:02 kernel: I/O error in filesystem > ("lvm(58,1)") meta-data > > dev 0x3a01 block 0xa00020 > > <4> Feb 7 11:20:02 kernel: ("xlog_iodone") error 5 > buf count 1024 > > <4> Feb 7 11:20:02 kernel: > xfs_force_shutdown(lvm(58,1),0x2) called from > > line 939 of file xfs_log.c. Return address = 0xc01b3cbc > > <4> Feb 7 11:20:02 kernel: Log I/O Error Detected. Shutting down > > filesystem: lvm(58,1) > > <4> Feb 7 11:20:02 kernel: Please umount the filesystem, > and rectify the > > problem(s) > > > > I've attached the oops (run through ksymoops) from this > particular umount. > > The snapshot is mounted ro,nouuid,norecovery. The source > of the snapshot > > contains an unmounted xfs filesystem, which was unmounted > at the time of > > snapshot creation. There has been no intentional I/O > activity to the > > snapshot, either. > > > > It looks to me like xfs is trying to flush something to > disk on the umount, > > even though the filesystem is read only and no recovery. I > would not have > > expected this. Is it correct behavior? > > > > I made the snapshot writeable, but kept the mount options > the same. I was > > able to mount/umount many times without oops, I/O errors, or > > xfs_force_shutdown. > > > > I did notice similar behavior when a full snapshot returns > an I/O error -- > > xfs_force_shutdown, with an oops following soon thereafter. > > > > 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. > > Had the same, disappeared when compiled the kernel with gcc-2.91.66 ! > Seems to be a compiler issue. > > Ciao > Klaus > > -- > Klaus Strebel > UNIX-Engineer > klaus.strebel@eigner.com > EIGNER - Precision Lifecycle Management - > <http://www.eigner.com> >
Attachment:
oops.out
Description: Binary data