Ups, sent via PM first. That what you get for CCing the author... On Tuesday 07 February 2012 16:04:49 you wrote: > On Tue, Feb 07, 2012 at 04:17:19PM +0100, Arnold Krille wrote: > > I did some similar test but with a slower machine and slower disk. > > The "problem" with distributed filesystems is the distributed locking. > > I'm not using a block-level distributed filesystem like GFS or OCFS. > > 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). > > And when the volume stretches across several machines, > > even though the reading might be done from the local disk, the locking has > > to be synchronized across all brick-machines. Another limit. > > Which locking is that? Can you point me to any documentation which says so, > or the part of the source code which implements it? I have to admit that I didn't yet read the source. > Why, when I simply read > a file, would a lock need to be created anywhere? 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. And since its a distributed filesystem, it has to be distributed locking. 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". And thats why I doubt that glusterfs doesn't do any locking (or synchronization of the fs-locks underneath). Have fun, Arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://gluster.org/pipermail/gluster-users/attachments/20120207/3cee08c0/attachment.pgp>
