Windows 11 24H2 and 25H2 Small file copy performance issues with Isilon H400 and H500 clusters

@JMACND ,

please create SR so Dell support can investigate.

@Phil.Lam​ Been there, done that, and they are looking at logs, but they keep sending an article that claims SMB overhead for small files is "normal." Right, it is, but that's not the case with our performance issues. We're seeing excessively long copy and save times, and it's worse for WAN users. 

@JMACND,

are you using L3 or metadata read / write for SSDs? I prefer metadata read/write for performance.

https://infohub.delltechnologies.com/sv-se/l/dell-powerscale-solution-design-and-considerations-for-smb-environments-2/performance-906/

Figure 6.   Comparison of L3 cache and other SSD usage strategies.

You may need to select different SSD strategy based on the workload. For most of workflows with write component, it is recommended to select Metadata Read/Write SmartPools SSD option. For repeated random read workloads, the recommendation is to use L3 cache and you will observe latency reduced. Figure 7 shows the decision tree of various (non-L3 cache) SmartPools SSD options, and their requirements and dependencies.

@Phil.Lam​ Thank you for this information. We do not have a license for Smart Pools, so we aren't leveraging that functionality...

@JMACND , 

Does the decision tree all end in Licensed Smartpools?

@Phil.Lam​ Here's our current strategy, I think...

@JMACND,

check what the nodepools are on now, L3 ?  You have to convert the cache SSD L3 -> storage first before using metadata read / write

isi storagepool nodepools list
isi storagepool nodepools view <h400.../h500...>

@Phil.Lam Not sure that this is the correct path though, given we weren't having any issues, and then within the last 2-3 months the issue started presenting itself as we deployed 24h2. ​

@JMACND ,  it coululd be SMB signing on Windows 11 24H2. Overall H400 and H500 may not have enough CPU cores to overcome it's demands.

https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/slow-smb-file-transfer 

SMB signing and SMB encryption are known to slow down SMB transfers. The amount of the performance loss depends greatly on the capabilities of the hardware involved. The primary factors are the count and speed of the CPU cores, and how much CPU time is dedicated to other workloads.

Starting with Windows 11, version 24H2 and Windows Server 2025, SMB signing is required by default. We don't recommend turning off the SMB client and server signing requirement, as they provide significant protection against spoofing, tampering, and relay attacks.

@Phil.Lam​ I understand that SMB signing should be on, but the performance is so terrible that the clusters are unusable for small file activity whether it be saving, opening or copying them. However, on Windows Server operating systems, the performance is more than acceptable. 

@Phil.Lam​ Also, I was able to reduce the SMB dialect to a version that doesn't require signing, and we were able to see non-encrypted SMB traffic run across the network... and the performance was the same. 

@JMACND , do you have InsightIQ (IIQ)?  maybe create another SR to inestigate what changed?

I know for sure usine meta read/write will improve performance.

Worked with Dell support, and they have determined that it may be either a Windows 24H2+ issue with SMB requests, or something in between our clients with that OS version and the Isilon clusters.