Network and Storage Protocols

Slow access database behaviour on netapp CIFS share



We have a application written on a access database (Yes, we are looking to replace the database, but it will take a while.) which works rather poor at the moment, we used to have this database on a novell OES machine and there the performance was bareable. The access database resides on a netapp cifs volume now. Since this migration the performance is judged as poor at best by the users.

During a Wireshark network sniff, the long waiting times always come back to the following SMB Sequence:

Time    Operation

0.00     NT Create AndX Request, Path:\path\to\our\database.ldb

0.10     microsoft-ds ACK on the previous comand.

1.03     NT Create andX Response: FID:0x0000, Error: Status_Shareing_Violation

These operations take almost 1 second. And on some screens you open you have 4 operations like this. So the user has to wait almost 5 seconds to switch screens.

The .ldb however always has a lot of locks: at the moment every user has 36 locks on the file with 12 users.

- The netapp is busy but not overloaded (CPU under the 10%, cache time: around 30 minutes and disk utilisations around the 20%)

- The application used to work desent on a novell server, so i can get little support from the application engineer.

The netapp is a fas3020 in a metrocluster solution with ontap version 7.2.4 running on it.

Any thoughts on troubleshooting this issue?



You may want to look at the oplock settings of the client and Netapp array  to see if this improves the performance of the database.

More about Oplocks here.

Array options -

options cifs.oplocks.enable


watan wrote:

Array options -

options cifs.oplocks.enable

It is probably better to disable oplocks on qtree level then on filer level.

qtree oplocks <path> [ enable | disable ]


It's possible that setting no_atime on the volume might help (I'd research that first though).



A long time has passed and all the suggestions have been tried. Non have helped though.

We managed to recreate this exact problem on a windows server. And it seems the problem lies within Access.

The solution for us: accepting the slowness and put the effort in moving the access databases to decent database servers.

Thanks a lot for thinking along.


We had the same performance issue with Microsoft Access file on Volume CIFS, I did a new volume dedicated for Access file only, with the parameter :

vol options vol1 no_atime_update on

Now it works fine, no performance problems anymore.

Thanks Andrew.


priv set advanced 

options cifs.SharingViolationDelay   0
options cifs.SharingViolationRetries 0
do a cifs restart 


Is it mandatory to restart CIFS for the changes to take effect?