On Tue, Feb 07, 2012 at 06:30:56PM +0100, Arnold Krille wrote: > > GlusterFS is a file-level protocol, more like NFS, and as far as I know > > there is no inherent locking between clients. > > There has to be locking. Otherwise two apps on two machines opening the same > file for writing would destroy each others changes. Therefor one client has to > gather locks on all brick filesystems (which is the same as synchronizing > access with all other clients). If two clients do a write() on the same area of the file, then one will get there first, and the second will overwrite the first. And if there were a lock, how would it help? Someone else please correct me if I'm wrong. > One client opens the file for reading, the other opens the file for trunc|write. > What do you get on the first client? How should this scenario be any save > without some kind of locking. If you want *useful* semantics in that situation then the clients can explicitly request an advisory lock on the file or ranges of the file, if they so wish. But this is not done for them by the filesystem. > I might be wrong and glusterfs really doesn't do any locking to prevent > concurrent write accesses. But if thats true, I think this rules out glusterfs > for any usage above "proof-of-concept". No such locking occurs when two concurrent processes on the same machine read and write a file, so why should it take place when the operation is over a network? Regards, Brian.
