Concurrency limitation?

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

 



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>


[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux