On Fri, 2002-01-04 at 21:10, Eric Sandeen wrote:
> Ok, I've done a bit of kdb sleuthing over here... it looks like it's
> blowing up shortly after lvm_snapshot_COW, although for some reason kdb
> says the backtrace is from sys_stat64 after the oops. On the other
> hand, setting a breakpoint at
> lvm_snapshot_COW, it oopses just a couple steps later. Here's the
> backtrace out of lvm_snapshot_COW. It gets there from lvm_do_lv_create
> via unlockfs; does this make sense? I didn't expect to get into
> lvm_snapshot_COW until after the snapshot volume was created...
Ok, it looks like that was the problem. XFS wrote the superblock when
unfreezing (unlocking) the filesystem, apparently LVM wasn't happy with
this I/O on the snapshotted volume before the volume had been created.
Something goes quite haywire as a result, but I'm not sure what.
We really don't need the superblock write at this point (it was the last
thing done prior to the freeze, no need to do it again), and removing it
allows the snapshot to be created without error.
I was curious, though, to see if reversing the order of unlockfs() &
lvm_fs_create_lv() at the end of lvm_do_lv_create() might alleviate
this problem (i.e. create the lv, THEN unlock the snapshotted volume)
but that didn't work, either. Perhaps the LVM folks can comment on
this...
Adrian says there's still a problem with overflows; I'll look into that.
-Eric
--
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@xxxxxxx SGI, Inc.
|