--tmac

Tim McCarthy

Principal Consultant

Clustered ONTAP Clustered ONTAP

NCDA ID: XK7R3GEKC1QQ2LVD RHCE5 805007643429572 NCSIE ID: C14QPHE21FR4YWD4

Expires: 08 November 2014 Expires w/release of RHEL7 Expires: 08 November 2014

On Wed, Feb 20, 2013 at 8:59 PM, Ray Van Dolson <rvandolson@esri.com> wrote:

We have an ONTAP 8.0.x filer here serving out a volume with an NTFS
qtree via both CIFS and NFS. We're encountering the following
situation:

1. An OSX user browses to the path via CIFS in Finder and then walks
away/moves on to another task leaving the Finder window open on the
path.
- This generates a mandatory read lock on the folder (verified via
lock status):
CIFS path=\path(/path) host=10.28.102.30() owner=njarecha state=GRANTED mode=Read-denyN oplock=None

2. An NFS client comes along now (automated build process) and attempts
delete the same folder. This appears to succeed from the NFS
client's perspective.
- We now see the following:
CIFS path=\path(/path) host=10.28.102.30() owner=njarecha state=GRANTED mode=Read-denyN oplock=None
CIFS path=\path(-) host= owner= state=GWAITING mode=DelOnClose

At this point, CIFS access to the path now is completely blocked. No
one can navigate into the folder, nor view its ACLs (save likely for
the OSX client still holding the read lock).

NFS clients can continue to access the contents of the folder (both
read/write), but rmdir/rm operations on the folder itself fail with
Permission denied.

The fix is to (a) close the Finder window or (b) clear the lock via
'lock break' on the filer.

I'll note that Windows Explorer doesn't appear to open a read lock when
you only browse to a path -- not sure why Finder does.

We're looking for options here, but first I'm wondering if the filer's
response here isn't ideal. Rather than completing closing off access
to CIFS clients, shouldn't #2 above just fail from the get-go rather
than generating the DelOnClose queued event (if a mandatory read lock
exists on the resource)?

Other options we're considering:

- Modifying automated processes to avoid the "rmdir" command.
- Sticking with only one access protocol (likely CIFS).
- Modifying OSX Finder behavior to not generate and hold a CIFS read
lock (not sure how easy this would be to do).
- Finding some sort of tunable on the ONTAP side to minimize impact
(e.g. ignore the read lock and let the NFS rmdir operation to
succeed) at the potential elevated risk of reduced data integrity.

Anyone have any thoughts/experiences with something similar?

Thanks,
Ray
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters