> > Does GlusterFS support concurent access to the files? Other words, what > happens if two diferent applications create, edit, or delete the same file > in same time!? > As of now, it behaves as per local disk behavior (ie, as in you handle same file on local disk from two different terminal). > I know that GlusterFS wrapes the regular (underlaying) file system. Does > it mean GlusterFS has all the capabilities off handling concurent file > access as the regular file system!? Currently we support flock(), and fcntl(), is there any other methods to handle locking? > > I found this in FAQs: > "Locking is handled distributedly across the bricks using > features/posix-locks translator. Namespace locking is handled by any one of > the designated glusterfsd server." > I corrected it. Thanks for pointing it out. > > So does it mean that designated GlusterFS server is the single point of > failure!? > This is used only by unify translator (this holds same for namespace option of unify), you can afr the namespace volume for avoiding single point of failure. > Ialso foud this in FAQs: > "NOTE: GlusterFS only supports fcntl() locks, as FUSE itself doesn't > support flock() calls." GlusterFS supports all the locking related syscalls, (if posix-locks translator is loaded on server side), but custom FUSE (till 2.7.2, haven't got time to work on 2.7.3) supports only fcntl(). If you need flocks() call also, then you need to use glusterfs patched fuse. > > Well, I must say that I'am totaly confused now. > -- Sorry for the not updated wiki pages, recently I didn't had enough time to work on them, so I will be correcting only once they are pointed out :). Regards, Amar > > -- Amar Tumballi Gluster/GlusterFS Hacker [bulde on #gluster/irc.gnu.org] http://www.zresearch.com - Commoditizing Super Storage!
