Why MapR Recommends 'hard' and 'nolock' NFS Mount Options?

Document created by mufeed on Feb 7, 2016
Version 1Show Document
  • View in full screen mode

Author: Mufeed Usman


Original Publication Date: April 29 2015


Why 'hard'?

MapR does not require a 'hard' mount for it's functioning, but is strongly recommended. This is actually very important if you want to have reliable performance of programs that use NFS. Since MapR either uses loop-back mounting against a local process (that gets automatically restarted if it ever crashes) or uses mounting against a pool of external servers, it should be very rare that this causes a problem. On the other hand, the problems with soft mounts typically show up right away.


Why 'nolock'?

MapR does not support NFS level file locking and hence urges to use 'nolock' option during its NFS mounts. MapR-FS does provide guaranteed at-once semantics for file creation. If you create a file in the usual Unix manner with the exclusive flag set you can be certain that no other application has created the same file. This is how most Unix applications have managed exclusive access to data since long before file locking.


Exclusive locking on distributed file systems has always been a grey area. The one thing that is typically guaranteed (and is guaranteed with MapR-FS) is that atomic create works exactly the way that you would expect. Thus, lock file protocols will operate correctly without having to explicitly set lock options.

1 person found this helpful