As long as the CIFS share and the NFS exports are not in the same volume ... FlexShare may be perfect for your needs.
With respect to what Greck was talking about ... in order to determine if disk iops are being limited by FlexShare, you'll want to use "stats" and observe the priorityqueue object, and pay attention to: priorityqueue:(default):usr_read_limit_hit:0 <-- user disk iops priorityqueue:(default):sys_read_limit_hit:0 <-- system disk iops
If those values become non-zero, you'll want to increase the global "io_concurrency": filer> priority set io_concurrency=<some number>
-- defaults to 8, max is 1024.
BTW, you need to be in advanced priv for this object:
filer> priv set advanced filer*> stats start -I foo priorityqueue wait 30 seconds or so filer*> starts stop -I foo
-----Original Message----- From: Cannon, Greck Sent: Sunday, February 08, 2009 9:40 PM To: Breen, Pat Cc: Adam McDougall; toasters@mathworks.com Subject: Re: How to balance volume priority (some NFS vs. CIFS)
Exactly what FlexShare is for... just keep in mind that disk iops *are* restricted based on the prioritization regardless of the load (it's a non-work-conserving queue), so monitor the appropriate statistics (I'm research inhibited at the moment, but prioqueue:usr_wait_msecs is close) to make sure things aren't waiting unnecessarily if there is still bandwidth to disk available.
--greck
On Feb 8, 2009, at 6:55 PM, "Pat Breen" pat.breen@netapp.com wrote:
Adam McDougall wrote:
Goal: reduce the impact of greedy clients (primarily known ones, but hopefully unexpected ones too) on the response time of the rest of the filer's clients. I don't care if the CIFS software share must accept
Adam -
I'd suggest taking a look at FlexShare (available since 7.2.x at no additional cost) which has been developed for exactly this problem.
It ONLY kicks in when there is contention of resources (eg. CPU, memory)
Prioritise the NFS workloads to high, and either leave the CIFS workload as is or set to low.
Regards,
Pat