[linux-lvm] massive LV corruption
Clint Byrum
cbyrum at spamaps.org
Tue Sep 14 20:41:53 UTC 2004
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
More information about the linux-lvm
mailing list