<p>Hi Atul,</p>
<p>Thanks a lot -- this is very helpful!</p>
<p>So assuming the application is performing the following fcntl() call to set a file segment lock:</p>
<p>    struct flock fl;<br>    int err;</p>
<p>    fl.l_type = F_WRLCK;<br>    fl.l_whence = 0;<br>    fl.l_start = 0;<br>    fl.l_len = 0;    /* len = 0 means until end of file */</p>
<p>    err = fcntl(file, F_SETLK, &fl);</p>
<p>I should be able to achieve the desired behavior if I enable cluster-wide locking with the /-o flock/ mount option.  Is this correct?</p>
<p>Thanks again!</p>
<p>Nochum</p>
<p>---------- Original message ----------<br>From: Atul Vidwansa <<a href="mailto:Atul.Vidwa...@Sun.COM">Atul.Vidwa...@Sun.COM</a>><br>Date: Jan 8, 1:30 am<br>Subject: Newbie question: File locking, synchronicity, order, and ownership<br>
To: lustre-discuss-list</p>
<p><br>Some comments inline..</p>
<p> </p>
<p> </p>
<p>Nochum Klein wrote:<br>> Hi Everyone,</p>
<p>> Apologies for what is likely a simple question for anyone who has been<br>> working with Lustre for a while.  I am evaluating Lustre as part of a<br>> fault-tolerant failover solution for an application component.  Based<br>
> on our design using heartbeats between the hot primary and warm<br>> secondary components, we have four basic requirements of the clustered<br>> file system:</p>
<p>>    1. *Write Order *- The storage solution must write data blocks to<br>>       shared storage in the same order as they occur in the data<br>>       buffer.  Solutions that write data blocks in any other order<br>
>       (for example, to enhance disk efficiency) do not satisfy this<br>>       requirement.<br>>    2.  *Synchronous Write Persistence* - Upon return from a<br>>       synchronous write call, the storage solution guarantees that all<br>
>       the data have been written to durable, persistent storage.<br>>    3.  *Distributed File Locking* - Application components must be<br>>       able to request and obtain an exclusive lock on the shared<br>
>       storage. The storage solution must not assign the locks to two<br>>       servers simultaneously.</p>
<p>AFAIK Lustre does support distributed locking. From <a href="http://wiki.lustre.org">wiki.lustre.org</a>:</p>
<p>    * /flock/lockf/</p>
<p>    POSIX and BSD /flock/lockf/ system calls will be completely coherent<br>    across the cluster, using the Lustre lock manager, but are not<br>    enabled by default today. It is possible to enable client-local<br>
    /flock/ locking with the /-o localflock/ mount option, or<br>    cluster-wide locking with the /-o flock/ mount option. If/when this<br>    becomes the default, it is also possible to disable /flock/ for a<br>    client with the /-o noflock/ mount option.</p>

<p>>    1.  *Unique Write Ownership* - The application component that has<br>>       the file lock must be the only server process that can write to<br>>       the file. Once the system transfers the lock to another server,<br>
>       pending writes queued by the previous owner must fail.</p>
<p>It depends on what level of locking you do. Lustre supports byte-range<br>locking, so unless writes overlap, multiple writers can write to same file.</p>
<p>Cheers,<br>_Atul</p>
<p> </p>
<p> </p>
<p> </p>
<p>>   1.</p>
<p>> Can anyone confirm that these requirements would be met by Lustre 1.8?</p>
<p>> Thanks a lot!</p>
<p>> Nochum<br>> ------------------------------------------------------------------------</p>
<p>> _______________________________________________<br>> Lustre-discuss mailing list<br>> <a href="mailto:Lustre-disc...@lists.lustre.org">Lustre-disc...@lists.lustre.org</a><br>><a href="http://lists.lustre.org/mailman/listinfo/lustre-discuss">http://lists.lustre.org/mailman/listinfo/lustre-discuss</a></p>

<p>_______________________________________________<br>Lustre-discuss mailing list<br><a href="mailto:Lustre-disc...@lists.lustre.orghttp://lists.lustre.org/mailman/listinfo/lustre-discuss">Lustre-disc...@lists.lustre.orghttp://lists.lustre.org/mailman/listinfo/lustre-discuss</a></p>