-----BEGIN PGP SIGNED MESSAGE-----
I have rerun my tests with the lvm patches applied in the correct order:
1) lvm-1.0.1 upgrade
With this case ext3 & resierfs are fine for creating snapshots, mounting
snapshots and being stable when snapshots overflow. However, XFS dies during
In this case where do you recommend I take this problem? LVM developers or
- From the backtrace it appears that it is ext3 that is actually dying - am I
reading this correctly? In which case does this need to be CC'd to the ext3
developers as well?
Do you think it is worth my while to upgrade ext3 and try again, considering
the problem is creating XFS snapshots?
While source volume mounted:
+ lvm-1.0.1 upgrade
(In that order)
* Can create ext3 snapshot? | yes
* Can mount a ext3 snapshot? | yes
* Can create resierfs snapshot? | yes
* Can mount a resierfs snapshot? | yes
* Can create xfs snapshot? | Oops
btp 1234 (lvcreate)
Running processes (lvcreate)
* Can mount a xfs snapshot? | Cannot test
When source & snapshot mounted:
* Cause oops when snapshot overflows? |
- ext3 | OK - Stable
- resierfs | OK - Stable
- xfs | Cannot test
On Thu, 3 Jan 2002 11:44, Adrian Head wrote:
> On Thu, 3 Jan 2002 04:05, Andreas Dilger wrote:
> > Note that you need to apply the VFS-lock patch AFTER the lvm-1.0.1
> > upgrade patch, otherwise that patch will reverse the VFS-lock patch!
> OK - thanks I will try this and rerun my tests.
> What I have found though is that the LVM_VFS_ENHANCEMENT in lvm.c gets
> removed with the lvm-1.0.1 upgrade patch. Is this the way it is supose to
> be? Isn't LVM_VFS_ENHANCEMENT needed anymore?
> > You should try ext3 from 2.4.18, or get it from the ext3 CVS (at
> > cvs.gkernel.sourceforge.net:/cvsroot/gkernel ext3). It has fixes
> > for a number of problems caused by error conditions while running.
> > If there is still a problem with ext3 oopsing with a full snapshot
> > (which is essentially an oops because of an I/O error on the disk)
> > then please file a separate bug report to the ext3 developers
> > (ext2-devel@xxxxxxxxxxxxxxxxxxxxx).
> > Cheers, Andreas
> Let me see if I understand this correctly:
> The problem of the kernel Oops when a snapshot overflows is actually a
> filesystem maintainer's/developer's problem because. The reason is that
> when a snapshot overflows it generates a disk full and it is up to the
> filesystem to deal with that and pass that error up the stack?
> Therefore, if there was an Oops on an:
> * ext3 snapshot I would have to tell the ext3 developer's/maintainer's
> * resierfs snapshot I would have to tell the resierfs
> developer's/maintainer's * xfs snapshot I would have to tell the xfs
> All I'm trying to do here is understand this a little more so that I can
> follow up with the correct people about these problems.
> Thanks Andreas for your time.
(Public Key available on request.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----