Re: [linux-lvm] massive LV corruption

[Clint Byrum <cbyrum spamaps org>]

On Tuesday, September 14, 2004, at 01:06 PM, Tracy R Reed wrote:

> On Tue, Sep 14, 2004 at 07:49:45AM -0700, Clint Byrum spake thusly:
> > Hans Reiser has stated that this is because each filesystem has a lock
> > on it, so while writing to, say, /home/cvs, anybody else who wants to
> > write to /home/cvs will have to wait. We have a CVS server where the
>
> That's odd given that each hard drive can only physically write to one
> place on the disk at a time anyhow due to head movement and that the
> kernel caches the writes and lays them back out on the disk with some 
> sort
> of elevator algorithm.

You're assuming that programs actually wait for disks! One process is 
creating a file at /home/cvs/dir1/#lockfile the other at 
/home/cvs/dir2/#lockfile. Until they run fsync, the physical disk isn't 
necessarily involved. The problem lies in the fact that with other 
filesystems, like XFS, the kernel will happily modify (at the VFS 
layer) two different dirs at one time, as they lock by meta-object (I 
won't say inode, because I don't think XFS has inodes). With ReiserFS, 
the entire partition is locked while things are modified. With a cvs 
lock file, you might not even want to call fsync() to send it to the 
disk, as the VFS layer will already have it there, and thats all you 
care about. This is one reason why using a secondary device as a 
journalling device can be so beneficial.. as you won't have to seek 
around the disk with every meta data update.

Somebody who knows what they're talking about.. feel free to shoot all 
of this down. I feel like I'm talking out of my arse a bit. ;-)

-cb