-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas, I have rerun my tests with the lvm patches applied in the correct order: 1) lvm-1.0.1 upgrade 2) VFS-lock With this case ext3 & resierfs are fine for creating snapshots, mounting snapshots and being stable when snapshots overflow. However, XFS dies during snapshot creation. In this case where do you recommend I take this problem? LVM developers or XFS developers? - 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? 2.4.17-xfs While source volume mounted: + lvm-1.0.1 upgrade + VFS-lock (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) journal_start ext3_dirty_inode __mark_inode_dirty update_atime do_generic_file_read generic_file_read sys_read system_call 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@lists.sourceforge.net). > > > > 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 > developer's/maintainer's > > 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. - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8M8yb8ZJI8OvSkAcRAjWvAJ4u1m2L2ECk23/zBuu/BEGXZ1EQnQCgmNHC WYtni02/ThZNBfKQ8LGH1qE= =CyfK -----END PGP SIGNATURE-----