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

Ouch, here's an odd one.


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

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.

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