PowerScale: OneFS: Performance degradation on Windows hosts running Version 24H2 and up

Users reports significantly differencing speeds when copying the same directory structure to or from PowerScale using Windows 11 or Windows Server on the 24H2 update or newer vs previous versions.  Actions such as running a search query against a directory may also see a significant increase in latency.

Windows client and Server update 24H2 introduces a new feature, FileNormalizedNameInformation and additional information levels for FileIdAllExtdBothDirectoryInformation, which currently is not supported by OneFS. This lack of support increases SMB overhead and because of this performance is impacted. 

Without FileNormalizedNameInformation or FileIdAllExtdBothDirectoryInformation support, the client triggers significant overhead while indexing, in terms of traversing the directory structure resulting in significantly more SMB calls, particularly “create” and “find” SMB calls, each taking time to process and for the client to receive (RTT). The higher the RTT, the more this issue is observed. 

When looking at a network trace of the issue, we see two variations. One is where the requested info class in the query is set to 0x30, which can be found with the filter smb2.find.infolevel == 0x30 (FileNormalizedNameInformation). The second variation asks for info class 0x51 (FileIdAllExtdBothDirectoryInformation), which can be found with the filter smb2.find.infolevel == 0x51.  While both present similarly, the latter is more impactful in search-heavy workflows.

Despite their similarities, they are handled separately and support was initially provided for info class 0x30 queries. Support for info class 0x51 queries is coming at a later date.

As of March 25th 2026, support for info-level 0x30 queries with this feature will be available in these OneFS branches:

• 9.10.1.7
• 9.13.1.x
• 9.14
• Any future OneFS versions

A short term solution until support is added to OneFS is to work with MicroSoft to stop the bfs filter which is responsible for FileNormalizedNameInformation from loading, this is a client side change and an MS ticket may be required for this. Note that this workaround is only applicable for the version of the issue where the failures are with info class 0x30, not 0x51.

Workaround for file-info-level 0x30:

To disable FileNormalizedNameInformation, this is done from the client.  

1. Via Powershell Admin mode  on the client(with admin rights), enter:
   

   C:> fltmc unload bfs

2. In order to keep the configuration after reboot of the PC, enter the following command using PowerShell Admin mode:

   C:> sc config bfs start= disabled

Disabling BFS may affect features that rely on normalized file names (e.g., certain security or indexing services).
Test in a non-production environment first.

You can re-enable BFS by running the below command and rebooting the client:

C:> sc config bfs start= demand

For the second version of the issue with queries involving info class 0x51, these are the currently targeted releases for the fix to grant full support as of August 25th, 2026. These include support for the info-level 0x30 calls as well.

• OneFS 9.7.1.17
• OneFS 9.10.1.9
• OneFS 9.13.1.2
• OneFS 9.15

Once the supported version of OneFS is installed, the following gconfig will need to be modified to enable support of this feature. Installing the correct version of OneFS does not automatically enable support of the feature. There is no service restart or client reconnection required to have the changes take effect.

isi_gconfig registry.Services.lwio.Parameters.Drivers.srv.SupportIdAllExtdBothDir=1

There is currently no workaround for the info class 0x51 queries.  Disabling bfs on the client does not prevent clients from sending requests with this info class.