Fresh off an ReFS volume that went RAW, I’ve decided to be equally reckless and disable the 8 dot 3 short names for my replacement NTFS volume. I was shocked to not find a single mention of it in this forum, so I’ll report back once this bad decision ends up in another catastrophic fail, but the numbers looks promising for the Storj trillion tiny file configurations.
Disable across system: fsutil behavior set disable8dot3
Strip existing: fsutil 8dot3name strip /f /s C:
I thought about this relic for a second, but seen not the possibility to tune it.
Thrilled to hear more about the effect.
Thank you for your scientific endeavors 
Day 6 of the ReFS restore: a race against disqualification. I’m halfway copied to the 8dot3 disabled volume, but the bottleneck is the read from the old ReFS volume at this point. If I manage to get back online in time I’ll see how long it takes to sort itself out and if it seems any faster at doing it.
For NTFS, you can also disable record of access time, like in Linux. I stumbled across some of my old notes:
And ofcouse, disable indexing from Drive properties > Index…
I recently finished a node transfer which took me like 28 days and the node survived without disqualification. The deadline seems to be 30 days.
Thanks for the info! I’ll definitely be done before 30 days with all files intact. ReFS just “forgot” it’s file tables. Hopefully with a noticeable 8dot3 boost in speed.
I hope your imprumevents won’t make NTFS nodes faster than ext4. 
I don’t want to rethink all my setups 
.
I don’t want to switch to linux eihter.
Inform me, when its faster than a RAM writecache. 
Tell me that when you find a way to have smaller inodes on NTFS 
Though, the 8dot3 thing does explain some part of why NTFS was observed to be so much slower than ext4 so far… I actually admire the extent to which Microsoft goes to keep compatibility with absolutely ancient software, but it does come with a cost.
Can the 8dot3 modifications be done only on new drives, without data? Or can they be applied on drives with data too? Do they corrupt data?
Regarding my mention for disabeling Last Access Time, you need to set it to 1, not 3.
The 3 option is lost on reboot.
You can run fsutil 8dot3name strip /f /s D: as mentioned above to strip the 8dot3 from an existing volume. You’ll need to disable it in the system to prevent it from creating new ones though.
So far NTFS is using 16.8 GB to store 2.35 TB of Storj tiny files with 8dot3 disabled, no idea if that’s more/less than with it turned on.
NTFS Volume Serial Number : 0x4602b03402b02b37
NTFS Version : 3.1
LFS Version : 2.0
Total Sectors : 19,532,869,631 (9.1 TB)
Total Clusters : 2,441,608,703 (9.1 TB)
Free Clusters : 1,805,320,435 (6.7 TB)
Total Reserved Clusters : 1,024 (4.0 MB)
Reserved For Storage Reserve : 0 (0.0 KB)
Bytes Per Sector : 512
Bytes Per Physical Sector : 4096
Bytes Per Cluster : 4096 (4 KB)
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 11.68 GB
Mft Start Lcn : 0x00000000000c0000
Mft2 Start Lcn : 0x0000000000000002
Mft Zone Start : 0x00000000257744a0
Mft Zone End : 0x0000000025780cc0
MFT Zone Size : 200.13 MB
Max Device Trim Extent Count : 0
Max Device Trim Byte Count : 0
Max Volume Trim Extent Count : 62
Max Volume Trim Byte Count : 0x40000000
How do you do that…?
Disable across system: fsutil behavior set disable8dot3
Strip existing: fsutil 8dot3name strip /f /s C:
You can make a small partition of 3 TB, enable 8dot3name for it, and copy the data from D:.
You can compare them and report back.
But this seems like a lot… @Toyoo said that for ext4, the parity is 1GB of fs for 1TB of data. I don’t think NTFS would be so off… Or I missunderstood something.
How do you check the size of fs?
This is likely updates or a new Windows version for pending rollout or a previous image of the same. It’s likely unrelated to the used storage.
But this one:
is relevant
PS > fsutil fsinfo ntfsInfo w:
NTFS Volume Serial Number : 0x6c6812b1681279d2
NTFS Version : 3.1
LFS Version : 2.0
Total Sectors : 1,953,519,615 (931.5 GB)
Total Clusters : 244,189,951 (931.5 GB)
Free Clusters : 21,827,983 ( 83.3 GB)
Total Reserved Clusters : 123,420 (482.1 MB)
Reserved For Storage Reserve : 0 ( 0.0 KB)
Bytes Per Sector : 512
Bytes Per Physical Sector : 512
Bytes Per Cluster : 4096
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 2.27 GB
Mft Start Lcn : 0x00000000000c0000
Mft2 Start Lcn : 0x000000000747057f
Mft Zone Start : 0x000000000d9f2e80
Mft Zone End : 0x000000000d9ff6a0
MFT Zone Size : 200.13 MB
Max Device Trim Extent Count : 0
Max Device Trim Byte Count : 0
Max Volume Trim Extent Count : 62
Max Volume Trim Byte Count : 0x40000000
Resource Manager Identifier : 1123004D-34D7-11DE-A90A-0002720194CE
PS > Get-PSDrive -Name w
Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- ---------------
W 848.71 82.80 FileSystem W:\
So in case of @AtomicInternet it’s like 4.9GB MFT for 1TB data.
In case of @Alexey that’s like 2.7GB MFT for 1TB data.
yes, but I deleted 8dot3 for the storage node folder only, and disabled it for the drive (I have other data on that drive also). But not 2.7GB/1TB, it’s:
and it’s GiB actually (we all know that this is a bug in all MS representations of storage and memory).
I calculated 2.27GB MFT for 848GB used.
Yep, I used 1024 base.
One thing: I read somewhere that drives formated by OS, in newer versions of Windows, have 8dot3name disabled. It’s only enabled for the system partition.
https://learn.microsoft.com/en-us/windows-server/storage/file-server/ntfs-overview
I wonder if the reported MFT size is fixed from the start, in the format faze, or varies with each file added or deleted?
Is it preallocated for the entire drive, like X bytes for Y bytes of data? Or X bytes per each data cluster?
I can see different MFT/Data in members posts:
https://forum.storj.io/t/disk-usage-discrepancy/24715/467?u=snorkel
https://forum.storj.io/t/disk-usage-discrepancy/24715/262?u=snorkel
https://forum.storj.io/t/errore-disk-space-used/8798/6?u=snorkel
So it’s dinamicaly allocated.
