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

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



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


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