Thanks, Basil. This setting seems to be a “global” setting for enabling/disabling oplocks feature on the NetApp. What the user is looking for is more fine-tuned control of specifying a list of files not to be impacted by oplocks, when enabled. Not sure if this capability is present in the NetApp, so wanted to reconfirm with the NetApp community. ☺

Eric

From: Basil [mailto:basilberntsen@gmail.com] Sent: Friday, October 31, 2014 1:02 PM To: Eric Peng Cc: toasters@teaparty.net Subject: Re: working with oplocks

I found thishttps://library.netapp.com/ecmdocs/ECMP1196993/html/GUID-526B365B-219B-4CA3-AD67-3E1E17B0DB0A.html:

"Disabling CIFS oplocks and lease oplocks disables all oplocks to or from the storage system."

On Fri, Oct 31, 2014 at 3:42 PM, Eric Peng <epeng@esri.commailto:epeng@esri.com> wrote: I have an end user who would like to be able to use a “veto oplock files” setting (found in Samba) on the NetApp, but from what I can tell this feature does not appear to be available. Seems to me that oplocks handling on the NetApp is more simplified (either enabled or disabled). Wanted to confirm if this is the case, or are there ways to emulate the “veto oplock files” setting feature on the NetApp? I am running SMB 2.0 on our NetApp (7-mode), DOT 8.1.4 P1.

Thanks, Eric

_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters

I just looked it up for you :

The *qtree oplocks* command enables or disables oplocks and lease oplocks for files and directories in a qtree or in a volume.If name is the path name to a qtree, the attribute applies to files and directories in the specified qtree. The path name to a quota tree does not need to end with a slash. If name is the path name to a volume, the attribute applies to those files and directories in qtree 0. The path name to a volume must end with a slash.

If the cifs.oplocks.enable option is off, oplocks are not sent even if you enable the oplocks on a per-quota-tree basis with the qtree oplocks command. The cifs.oplocks.enable option is enabled bydefault.

Hope that helps...

Sebastian Am 31.10.2014 21:30 schrieb "Basil" basilberntsen@gmail.com:

I'm pretty sure that's the only granularity of control Netapp offers.

On Fri, Oct 31, 2014 at 4:26 PM, Eric Peng epeng@esri.com wrote:

...

Thanks, Basil. This setting seems to be a "global" setting for enabling/disabling oplocks feature on the NetApp. What the user is looking for is more fine-tuned control of specifying a list of files not to be impacted by oplocks, when enabled. Not sure if this capability is present in the NetApp, so wanted to reconfirm with the NetApp community. J

Eric

*From:* Basil [mailto:basilberntsen@gmail.com] *Sent:* Friday, October 31, 2014 1:02 PM *To:* Eric Peng *Cc:* toasters@teaparty.net *Subject:* Re: working with oplocks

I found this https://library.netapp.com/ecmdocs/ECMP1196993/html/GUID-526B365B-219B-4CA3-AD67-3E1E17B0DB0A.html :

"Disabling CIFS oplocks and lease oplocks disables all oplocks to or from the storage system."

On Fri, Oct 31, 2014 at 3:42 PM, Eric Peng epeng@esri.com wrote:

I have an end user who would like to be able to use a "veto oplock files" setting (found in Samba) on the NetApp, but from what I can tell this feature does not appear to be available. Seems to me that oplocks handling on the NetApp is more simplified (either enabled or disabled). Wanted to confirm if this is the case, or are there ways to emulate the "veto oplock files" setting feature on the NetApp? I am running SMB 2.0 on our NetApp (7-mode), DOT 8.1.4 P1.

Thanks,

Eric

---

Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters

---

Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters