Disable the DOS 8.3 short file names on windows VM's

[Rudi Feijó]

We have been looking for ways to speed up file operations in our windows servers, and I came across this article which explain we should disable DOS 8.3 file names on windows machines :

https://www.getfilecloud.com/blog/2016/05/a-guide-to-improve-windows-file-server-performance/#.XfvQuGRKiMp

I have never heard about this before so I'm wondering if anyone have any experience disabling this setting, or if it may have some unwanted consequence on Windows VM's on GCE

[Vivak Patel]

I've tried to remove the DOS 8.3 file name as per the article, but I get "Error: Access is denied." when running any of the suggested commands. It may not be possible to remove it in the first place as Google may have customized the image to run on Compute Engine. Although I didn't find information on these changes, you could see some of the differences between the GCE image and the baseline Windows image on this link.

[Kirill Katsnelson]

I never ran Windows machines on GCE, but I've been disabling the short filenames names since Windows 2000. Never had problems with it on both physical and Hyper-V machines.

As a word of caution, I did that by setting a registry key to disable generating 8.3 names for new files (this was long before fsutil existed) on a fresh, but already booting system, I do not know the implications of removing the existing 8.3 aliases on files in the system. But leaving them alone won't likely slow you down, so you may pretty safely disable them but skip the second step, the removal of them.

16-bit software for Windows 3.1 would break. I have no idea if it still exists, and even if modern Windows can run it, but since your bank is more likely than not to run a COBOL accounting program on a mainframe... YMMV.

Some old program may expect 8.3 names available, but, again, unlikely. Test.

But since you are on GCE, it's just way too easy to snapshot a machine, give it the 8.3 epilation and see what happens. If it boots, you're likely ok with everything else. Also, if you forcibly remove them, and some software that is already installed and configured depends on them, you'll learn about it sooner. It was not uncommon in the past to see paths like C:\PROGRA~1\... written to the registry or configuration files by older software, but those days are likely gone.

The performance boost you'd get won't be tremendous in general, unless your software creates and kills millions of small files--then it may be substantial.

Ah, and TIL about fsutil, thanks!

And,

We have been looking for ways to speed up file operations in our windows servers, and I came across this article which explain we should disable DOS 8.3 file names on windows machines :

when you are trying to speed up anything, the first step is to determine what is slowing it sown. It's not clear from your question whether or not you identified the culprit, but just in case: Windows is packed with performance tools and kernel hooks for them up to the brim; if the root cause of slowdown is really with creating new files, then you're on the right track. Google "xperf", there is a lot of both docs and tutorials on performance tracing.

  -kkm

[Kirill Katsnelson]

On Thursday, December 19, 2019 at 1:49:38 PM UTC-8, Vivak Patel wrote:

I've tried to remove the DOS 8.3 file name as per the article, but I get "Error: Access is denied."

You need an elevated command prompt to run the tool, a.k.a. "Run as administrator".

 -kkm

[Kirill Katsnelson]

Rudi, the manual is very helpful: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name#syntax

Apparently, the tool can scan the registry for the thing I mentioned, or run in "test" mode and tell you if it's unsafe to remove the 8.3 names. Naturally, it cannot tell you that it is safe with certainty.

And if I'm to believe the OS manual, the /s does not do what the guide that you are linking to suggests it does.

 -kkm

[Kirill Katsnelson]

Rudy, another note, as I feel I have misled you to a degree, so let me right that wrong. The fsutil tool is not as smart as it promised to be, so some manual analysis would probably required.

It can scan the registry for values that appear to be 8.3 aliases for longer path names. Apparently, it considers "unsafe" any directory or file reference that contains a tilda '~' in the name (and it's ok to have a bona fide tilda in an NTFS name). It produces a kerzillion of false positives for names that by far do not fit into the 8.3 pattern.

Run, in an elevated console, 'fsutil  8dot3name scan /s c:' (for some value of 'c:'). The tool will write a long log file into the %temp% directory. The first part of this log will be useful.

At first, it says "Scanning registry...". This is where you'd get useful data. As soon as it says "Scanning 8dot3 names...", kill it. It's a long process, and the scan results are useless.

Next, go to the %temp% directory and locate the new log file, and examine it. I like the good old Explorer, it's Win+E Alt+D %temp% Enter; in any case, locate the file matching the '8dot3_removal_log*.log' pattern. This is where it gets ugly. In the first pare, every line has a value in the first column, and the registry path to it in the second one. Some matches are clearly genuine, e. g.,

c:\PROGRA~2\COMMON~1\ADOBEA~1\Versions\1.0\ADOBEA~1.EXE,1                         HKCR\AIR.InstallerPackage\DefaultIcon

This program will break if you remove a 8.3 alias of either component in the path. Fair enough, I own antiquated Acrobat 9, and do not upgrade as it's doing all I want, while newer versions changed licensing and want a yearly subscription. But most of the values are simply listed for being guilty of containing a tilda anywhere in the value! Here are two flagrant examples of false positives from the log:

C:\Program Files\WindowsApps\Microsoft.BingWeather_4.34.13393.0_neutral_~_8wekyb3d8bbwe  HKCR\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\PackageRepository\Packages\Microsoft.BingWeather_4.34.13393.0_neutral_~_8wekyb3d8bbwe

This is not a 8.3 filename, it simply contains a '~' in its long filename. It looks like most if not all Windows Store packages do! Another false positive is listed just for the crime of having the '~' withing a command line, referencing the home directory

"C:\Program Files (x86)\clink\0.4.9\clink.bat" inject --autorun --profile ~\clink  HKU\S-1-5-21-760362315-3816794934-3073496412-1001\Software\Microsoft\Command Processor

It seems that a good regular expression would filter all this noise out. But there is a third category, a genuine NTFS names with a tilda falling into the 8.3 pattern. These are well-known directories related to Windows setup and upgrade. They do not really have an 8.3 alias name; their one and only name contains a '~' and matches the 8.3 pattern, for example,

\\?\C:\$WINDOWS.~BT\Work\814D4682-AF31-490B-8F50-5556C90DDF26\                    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Containers-ApplicationGuard-Package~31bf3856ad364e35~amd64~ru-RU~10.0.18362.1

The \$WINDOWS.~BT\ directory is a real thing, a hidden directory related to OS servicing and upgrades, but it's not an 8.3 alias. There are a few hidden directories like that; $Recycle.bin is another example (fortunately, this one did not pop up in search). So it's reasonable to exclude these from your analysis. FWIW, it does not even currently exist on my machine (and how these ru_RU packages got in the picture is a mystery; I only installed Office spelling tools for Russian, among few other languages. Windows behaves in all the mysterious ways). Easy to grep them away, as their name always starts with the dollar sign '$'.

So in my case, there is a couple programs that actually use and may possibly rely on existing 8.3 names. But it's unlikely you'll encounter any of these on the server; certainly none of modern Microsoft tools and services.

To wrap all this up, my advice is install a fresh system, disable 8.3 aliases for new files on all volumes with 'fsutil 8dot3name set 1', and leave the existing ones: they won't affect performance. It's only the creating of new ones that can cause a perf hit. You also have an option to disable them on specific volumes, if you run into a trouble (FWIW, I never did).

The second part of the listing (if you let it run to the end) is, essentially, a boring to death list of all files and their 8.3 aliases. No point looking at them. It's safe to assume that they always created until the generation of the 8.3 aliases had been explicitly disabled. This is why it's the first thing I do on a new installs (but this is an HP laptop, so I did not install the OS here).

I would also suggest disabling the updates of last access times on files (akin to Linux noatime mount option) unless you rely on them; run 'fsutil behavior set disablelastaccess' for a short help. With this enables, any access to file or its attributes results in an eventual disk write operation.

A third disk performance thing is the cache behavior. Normally, all disks (this is a per-disk, not per-volume setting) have a write-back caching, when the data is written as soon as possible, and a write API call does not complete until the data is  journaled. Turning off write-back caching mode improves performance at the price of reliability: the write operation completes as soon as the journaling data is cached in the controller cache (on a physical machine). To avoid corruption of a filesystem, this is not a recommended mode of operation unless the physical RAID controller has a battery backing up its cache, but in the cloud VMs this is less of a concern. An internal system failure (kernel bug check, aka BSOD) can have consequences, but in GCE virtual hardware does not experience hardware failures or power outages, so this may be an option to consider. Research into this option, too. Depending on how stringent your RPO requirements are, you can have periodic snapshots that would allow a recovery even if it comes to the worst corruption, so that write-back with frequent snapshot look like a good recipe to get a perf improvement, provided that the RPO allows some data loss.

If you have a domain, you can do all of the above using group policies, so that they are applied to any server joining the domain, and you do not have to worry about configuring individual servers.

Hope this is helpful.

 -kkm

On Thursday, December 19, 2019 at 11:39:08 AM UTC-8, Rudi Feijó wrote: