[linux-lvm] RE: Oops unmounting snapshot of xfs filesystem
Stephenson, Dale
dstephenson at snapserver.com
Mon Feb 18 13:34:02 UTC 2002
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 at snapserver.com
> -----Original Message-----
> From: Klaus Strebel [mailto:klaus.strebel at eigner.com]
> Sent: Monday, February 11, 2002 2:46 AM
> To: Stephenson, Dale
> Cc: 'linux-xfs at oss.sgi.com'; 'linux-lvm at 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 at eigner.com
> EIGNER - Precision Lifecycle Management -
> <http://www.eigner.com>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oops.out
Type: application/octet-stream
Size: 3575 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20020218/9145c6db/attachment.obj>
More information about the linux-lvm
mailing list