Hi, This is based on ext3 0.0.5e and latest LVM snapshot from Sistina CVS. I've been playing with LVM snapshotting in that I'd been getting system hangs and trying to help resolve that issue, but in the process today I stumbled upon an interesting side-effect. This is on my laptop, running 2.2.18 with loads of patches and above LVM and ext3. Basically, forewarning, all of this was done on a loop device. The loop device was bound to a file on an ext3 filesystem. (If this brings up any apparent issues to start with). Next, on the loop device I created an LVM device, formated, yada, yada. Mounted the new lvm filesystem which was ext2 based, (didn't add any journaling to it) and ran my tests that I've been running. Locked my box and powered off/on. Upon coming back up, journal replays just fine on ext3 filesystem that the loop device file resides on. On a *seperate* ext3 filesystem all replay is fine also. Now on this second ext3 filesystem I have a local CVS repository and I keep things like kernel in here for generating and tracking all my diffs, etc. :) Upon reboot after the lockup though my CVS is a bit 'odd'. Basically I'm getting the following cvs error: cvs [rtag aborted]: EOF in value in RCS file /opt/cvs/kernel/linux/arch/alpha/boot/main.c,v Now looking at the file it's complaining about I'd expect it to be main.c, but it turns out it's a shortened version of md_k.h that typically lives in linux/include/linux/raid/md_k.h. Somehow inodes get repointed to wrong areas or something? Any ideas? :) Well, I'm off to fix the borken bits, hopefully there are many more of these mismatched files.
Oh, I should add I was using this cvs repository in the bg while testing on the loop device. Hence, obviously things were happening with with the files in cvs.
Jay writes:> Locked my box and powered off/on. > > Upon coming back up, journal replays just fine on ext3 filesystem that the > loop device file resides on. On a *seperate* ext3 filesystem all replay > is fine also. Now on this second ext3 filesystem I have a local CVS > repository and I keep things like kernel in here for generating and > tracking all my diffs, etc. :)> Upon reboot after the lockup though my CVS is a bit 'odd'. Basically I'm > getting the following cvs error: > > cvs [rtag aborted]: EOF in value in RCS file > /opt/cvs/kernel/linux/arch/alpha/boot/main.c,v > > Now looking at the file it's complaining about I'd expect it to be main.c, > but it turns out it's a shortened version of md_k.h that typically lives > in linux/include/linux/raid/md_k.h.If you are not running in "data=journal" mode, there is no guarantee that the data made it to disk, only that the metadata is OK. This is true for ext2 as well. I assume CVS should do a sync() or something to keep the repository correct. I guess we need to determine if that is true, otherwise the bug is in CVS. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Hi, On Fri, Feb 02, 2001 at 01:06:58PM -0800, Jay Weber wrote:> > Upon reboot after the lockup though my CVS is a bit 'odd'.Is this reproducible? Were there any kernel logs anywhere? Have you ever seen this without LVM and/or loopback devices in the picture? Cheers, Stephen