I have been persevering for a while with this one.  I have a folder which has 18,000 folders underneath it.  When I browse to this directory it takes windows 11 about 7 seconds (on server 1) to 15 seconds (on server 2) to go though and list all the folders, even if I was just in there.

 

I have tried the Dynamix FolderCache plugin which did not help at all.  Wondering if there is something in Windows or the SMB config that I can adjust to make this better.

 

Server 1 which takes approximately 7 seconds to list the folder:

Motherboard: Asus Pro WS WRX80E-SAGE SE WIFI

CPU: Threadripper Pro 3975WX

RAM: 128GB DDR4 ECC

Drives: 10 x Seagate ST20000NM0002D, 8 data 2 parity

Lan connection: 10gb

 

Server 2 which takes approximately 15 seconds to list the folder:

Motherboard: Asus Pro WS WRX80E-SAGE SE WIFI

CPU: Threadripper Pro 3975WX

RAM: 128GB DDR4 ECC

Drives: 12 x Seagate ST16000NE000, 10 data 2 parity

Lan connection: 10gb

 

I have multiple Windows machines, one with 10gb LAN and the second with 2.5gb.  Both are Windows 11 but were previously Windows 10 and exhibited the same behavior.

 

No changes have been made to the server or clients, all stock settings.  The time difference between the two servers leads me to believe it could potentially be a FUSE filesystem bottleneck.  There is no noticeable CPU increase while the directory is being listed.

 

Any help appreciated and if I have missed some critical information please ask :)

 

4 hours ago, Phibster said:

could potentially be a FUSE filesystem bottleneck

Most likely, it's especially noticeable with many small files, workaround for now is to use disk shares or an exclusive pool whenever possible, Linux kernel 6.9 has a new FUSE passthrough option, that should hopefully improve FUSE performance by a lot, if the posted benchmarks are an indication, it should perform almost like native, it's expected that Unraid 7.0 will use that kernel as soon as openzfs supports it, first beta should be out very soon.

One thing that might help is to make sure that at the Windows end you are not using one of the 'icon' views for displaying the results.

16 hours ago, itimpi said:

One thing that might help is to make sure that at the Windows end you are not using one of the 'icon' views for displaying the results.

 

The folder is simply a list of folders (each folder has a file underneath it) but no files in that folder.  I absolutely hate the icon views and use detailed view only.  Even changing to the 'list' view still has the same slow response so it's not the extra details being read.  It is possible windows is still being silly and trying to 'peek' into folders as well which would slow it down.

17 hours ago, JorgeB said:

Most likely, it's especially noticeable with many small files, workaround for now is to use disk shares or an exclusive pool whenever possible, Linux kernel 6.9 has a new FUSE passthrough option, that should hopefully improve FUSE performance by a lot, if the posted benchmarks are an indication, it should perform almost like native, it's expected that Unraid 7.0 will use that kernel as soon as openzfs supports it, first beta should be out very soon.

Oh that would be good to see.  I am also eagerly awaiting the move to kernel 6.2 which supports the intel ARC GPU which I have one sitting waiting so I can do some transcoding.

7 hours ago, Phibster said:

have one sitting waiting so I can do some transcoding.

Beta 7.0 was just released, currently on kernel 6.8

Thank you, will test it out on my secondary server first. 

So testing Beta 7.0 on my second machine and I see some improvement but still approximately 7-8 seconds (down from about 15) but still not amazing so I will wait for the proper release before I upgrade my main server.

Performance improvement is only expected from kernel 6.9 on, current beta uses 6.8

I've switched all my shares to SMB from NFS now that I've stopped using the array and moved them to a ZFS Pool. Every one is Exclusive and no longer goes through FUSE.  Instant directory listings and maxing out 1GbE network at the moment.