I came across a snippet in the sqlite FAQ that warns against using
some network file-systems due to file locking bugs. In the past I've
had excellent experiences using NFS+Linux (CentOS) so was wondering if
people had comments if or not this (fairly vague) warning might apply
to NFS or not at all?
>From the sqlite FAQ:
.........the file locking logic of many network filesystems
implementation contains bugs (on both Unix and Windows). If file
locking does not work like it should, it might be possible for two or
more client programs to modify the same part of the same database at
the same time, resulting in database corruption..........
Does file-locking in NFS work "as it should". Is this dependent on the
particular options I pass to the NFS mount? e.g. I usually use hard
mounts with the intr option.
A snippet from my fstab:
eustorage:/opt /opt nfs
rw,nodev,noatime,nfsvers=3,timeo=110,retrans=50,hard,intr,proto=udp,rsize=32768,wsize=32768
0 0
If I desired the ideal file-locking properties should I be modifying /
adding any particular option?
--
Rahul
On Aug 13, 2010, at 4:54 PM, Rahul Nabar wrote:
> I came across a snippet in the sqlite FAQ that warns against using
> some network file-systems due to file locking bugs. In the past I've
> had excellent experiences using NFS+Linux (CentOS) so was wondering if
> people had comments if or not this (fairly vague) warning might apply
> to NFS or not at all?
>
> From the sqlite FAQ:
>
> .........the file locking logic of many network filesystems
> implementation contains bugs (on both Unix and Windows). If file
> locking does not work like it should, it might be possible for two or
> more client programs to modify the same part of the same database at
> the same time, resulting in database corruption..........
It's really not clear what is meant by this vague warning. Maybe you should ask for details from the sqlite development community.
> Does file-locking in NFS work "as it should". Is this dependent on the
> particular options I pass to the NFS mount? e.g. I usually use hard
> mounts with the intr option.
> A snippet from my fstab:
>
> eustorage:/opt /opt nfs
> rw,nodev,noatime,nfsvers=3,timeo=110,retrans=50,hard,intr,proto=udp,rsize=32768,wsize=32768
> 0 0
>
> If I desired the ideal file-locking properties should I be modifying /
> adding any particular option?
You have two choices on Linux clients: "lock" and "nolock". They control whether file locks appear to other clients or not. I assume your applications cares about serialization with processes only on the same client where it is running. Mount options almost certainly do not matter in this case.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Fri, Aug 13, 2010 at 4:15 PM, Chuck Lever <[email protected]> wrote:
>
> It's really not clear what is meant by this vague warning. ?Maybe you should ask for details from the sqlite development community.
Thanks Chuck! The warning seemed pretty vague to me as well. Just
thought I'd doublecheck if there was something obvious I was missing.
Thanks for your comments.
>
> You have two choices on Linux clients: ?"lock" and "nolock". ?They control whether file locks appear to other clients or not. ?I assume >your applications cares about serialization with processes only on the same client where it is running. ?Mount options almost certainly >do not matter in this case.
>
I do have locking enabled. I'm not using "nolock" as a option and I
have lockd daemon running.
--
Rahul
You can read from /proc/locks file at the server. This will give you the list
of all locks on the server. Then you can filter out NFS relevant information,
say, based on the inode number.
Vasily
On Fri, Aug 13, 2010 at 03:09:39PM -0700, Risto Bell wrote:
> From client, how to remotely query server for list of locks held?
> Helpful if debugging lock recovery failures.
>
> ---------------------------------------------------------------
> This message and any attachments may contain Cypress (or its
> subsidiaries) confidential information. If it has been received
> in error, please advise the sender and immediately delete this
> message.
> ---------------------------------------------------------------
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
From client, how to remotely query server for list of locks held?
Helpful if debugging lock recovery failures.
---------------------------------------------------------------
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---------------------------------------------------------------