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

Re: [linux-lvm] massive LV corruption

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. ;-)


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