3 ms·

The IMHO extremely relevant point is in the very end of the actual specifications: https://docs.microsoft.com/it-it/windows/win32/fileio/exfat-specification ht

by jaclaz 7y ago

The IMHO extremely relevant point is in the very end of the actual specifications: https://docs.microsoft.com/it-it/windows/win32/fileio/exfat-specification https://docs.microsoft.com/it-it/windows/win32/fileio/exfat-... >26-Aug-2019 Seventh release of the Basic Specification, which includes the following changes: Updated legal terms pertaining to the specification, including: Removal of Microsoft Confidential notice Removal of Microsoft Corporation Technical Documentation License Agreement section Updated copyright notice to 2019 Till now the documentation wasn't AFAIK publicly available or it was anyway "restricted".

userbinator 7y ago
Skimming through the doc, it looks like a modification of FAT32 with some (noticeably more complex) extensions, and not anything resembling what you might envision a "FAT64" to be; a FAT is still a linked list of 32-bit entries, there can still be two of them, and directory entries are still 32 bytes each (although defined in a rather complex way.) There's a separate allocation bitmap, which seems redundant and a waste of space (and code) given that the FAT itself already contains the information in previous versions. I've written a FAT12/16/32 driver for an embedded system before; and oddly enough, the documentation I had at the time was far easier to understand than this one. I didn't expect exFAT to be this complex, or perhaps the doc is just excessively verbose --- for example, the whole first paragraph of the 4th section is saying nothing more than "there may be 1 or 2 FATs, one after the other, and NumberOfFats is the field that says how many there are" except it takes 5 sentences to do so. That said, this spec is written in a style that's easier to understand than a lot of the other "open specifications" docs that MS has released, but I suspect that's because this one was once an actual NDA'd implementer's document rather than the others which I've heard may have been released purely for legal reasons related to the antitrust than anything else. Now if only they'll do this for NTFS...
- MuffinFlavored 7y ago
  With how slow modern day NTFS is for things like node_modules (lots of nested directories), I can't help but hope some better file system will become widespread on the next major Windows release.
  - kevingadd 7y ago
    Most of the performance issues are not NTFS so much as the prevalence of file-system filter drivers. This is why WSL had so many file-system performance issues despite the fact that it was using a custom FS. IIRC this also motivated the move to WSL2 from what I read, since a virtual machine can use a small set of files to store a whole FS. EDIT: See here - https://github.com/Microsoft/WSL/issues/873#issuecomment-425272829 https://github.com/Microsoft/WSL/issues/873#issuecomment-425...

by jaclaz 7y ago

userbinator 7y ago

Skimming through the doc, it looks like a modification of FAT32 with some (noticeably more complex) extensions, and not anything resembling what you might envision a "FAT64" to be; a FAT is still a linked list of 32-bit entries, there can still be two of them, and directory entries are still 32 bytes each (although defined in a rather complex way.) There's a separate allocation bitmap, which seems redundant and a waste of space (and code) given that the FAT itself already contains the information in previous versions. I've written a FAT12/16/32 driver for an embedded system before; and oddly enough, the documentation I had at the time was far easier to understand than this one. I didn't expect exFAT to be this complex, or perhaps the doc is just excessively verbose --- for example, the whole first paragraph of the 4th section is saying nothing more than "there may be 1 or 2 FATs, one after the other, and NumberOfFats is the field that says how many there are" except it takes 5 sentences to do so. That said, this spec is written in a style that's easier to understand than a lot of the other "open specifications" docs that MS has released, but I suspect that's because this one was once an actual NDA'd implementer's document rather than the others which I've heard may have been released purely for legal reasons related to the antitrust than anything else. Now if only they'll do this for NTFS...

MuffinFlavored 7y ago
With how slow modern day NTFS is for things like node_modules (lots of nested directories), I can't help but hope some better file system will become widespread on the next major Windows release.
- kevingadd 7y ago
  Most of the performance issues are not NTFS so much as the prevalence of file-system filter drivers. This is why WSL had so many file-system performance issues despite the fact that it was using a custom FS. IIRC this also motivated the move to WSL2 from what I read, since a virtual machine can use a small set of files to store a whole FS. EDIT: See here - https://github.com/Microsoft/WSL/issues/873#issuecomment-425272829 https://github.com/Microsoft/WSL/issues/873#issuecomment-425...