Unraid 7.0.1 on Dell T440.

A share is set up with Export=Yes and Security=Private.

The client is a Windows 10 machine used for video production- reasonable performance with i7-6700K and 64G of RAM. I need to clean up thousands of old video clips on the Unraid Array.

I select the files in the Windows File Explorer browser and hit Delete.

I see the usual windows dialog showing progress, but it is moving extremely slow. (image below)

Estimating 5.5 hours to delete the directory of 8700 files.

Copying files to/from the Unraid server has been at reasonable speed, nothing like this 100x slowdown on deleting.

Unraid CPU is 10-12% while it is working on deleting.

Windows estimates the speed as .33 items/second. Or 3 seconds per deleted file???

Nothing notable seen in the Unraid log.

Yes I could ssh into the Unraid server and delete files from the terminal. But my expectation is that Unraid should perform at least on par with the 15 year old Windows server it is replacing. Especially on regular tasks such as interacting with the file system from Windows Explorer.

How should I diagnose the problem?

If they are small files, FUSE takes a big hit, if it's a pool you can enable exclusive mode.

@JorgeB, so you saying that the poor deleting performance is normal and expected?

So the overhead is due to FUSE. However during the hours-long deleting process, there was no processor use on the server above background. What is causing the bottleneck?

I searched for "exclusive mode". It does not appear to be mentioned in the docs, but I found a bit in the update on Version 6.12.0 2023-06-14.

It is not clear what is exclusive about it, and whether it would apply to my setup. My shares have Array as primary, and included disks All.

What is the downside of exclusive mode? Why wouldn't it be defaulted to On for all shares if there is such a performance difference?

Edited June 21, 20251 yr by timg11

I would suggest that you use the File Manager built into the recent versions of Unraid. Not sure if it will be that much faster but it will then be a completely background process and the time to completion should not be that big an issue. With it, you can also delete at the disk level which will totally bypass FUSE. The built-in file manager will tell you which disks contain files for each Share so you know which ones you have to check and delete as required. Remember that you also have to update parity during a delete operation which also takes time.

(To be fair, so are Windows File Explorer operations. I am pretty sure that Windows OS assigns a pretty low priority on file managing processes. [I know that I don't want video playback stuttering so a file deletion process will be a bit faster!] The disadvantage with using File Explorer is that as the Windows client has to be on and it uses up a small bit of LAN bandwidth.)

Edited June 21, 20251 yr by Frank1940

17 hours ago, timg11 said:

so you saying that the poor deleting performance is normal and expected?

If there are many small files it can be very noticeable, if you are using the array you cannot use an exclusive share, but as a test, you can delete a folder suing the disk path instead of the share path, that will also get around FUSE e.g.;, rm -r /mnt/disk#/share/path/to/folder