3 ms·
>NTFS was properly designed with real use cases in mind to avoid fragmentation where possible. Once said that NTFS was very properly designed (and still works
by jaclaz 9y ago
>NTFS was properly designed with real use cases in mind to avoid fragmentation where possible.
Once said that NTFS was very properly designed (and still works fine after some 25 years with only a very few modifications and on relatively huge volumes) it does have a few "strange" characteristics.
JFYI, a strange case when there was apparently no solution (due to some queer placement of the NTFS filesstem structures), a 6 Gb file couldn't be stored contiguous on a 8 Gb USB stick (and of course FAT32 wouldn't have allowed a bigger than 4 Gb file):
http://reboot.pro/topic/18022-error-60-file-for-disk-emulation/ http://reboot.pro/topic/18022-error-60-file-for-disk-emulati...
- dspillett 9y ago> due to some queer placement of the NTFS filesstem structures It isn't really queer: some core, regularly accessed, structures are deliberately in the middle of the filesystem to reduce head movements in the common use case of it being a single volume (or the most significant volume for the currently IO tasks) on a spinning-disk-and-floating-heads based drive. This essentially splits free space in two from the very start so an 8Gb volume is going to start with two ~4Gb ranges of unallocated space not one single 8Gb range. ext* filesystems distribute group descriptors, superblock backups, and other structures, around volumes instead of keeping them at one end, for simialar reasons. See https://www.slashroot.in/understanding-file-system-superblock-linux https://www.slashroot.in/understanding-file-system-superbloc... and much other online documentation. (though spreading the superblocks around isn't a performance thing, it is to reduce the damage potentially caused by localised physical disk corruption) The queer part is software coupling itself so tightly with the storage layer such that it can't cope with a file not being physically 100% contiguous. The example in that link sounds like a virtualisation method trying to be very aggressive about optimising the mapping between guest disk access and physical storage (which might convey a small performance benefit) - if you are optimising like that then you are probably better off trying to use raw block devices rather than files on a host filesystem.
- jaclaz 9y agoWell, the point is that after the 2000's some new hard disk like devices (including USB sticks and SSD's) have been available and became common in use, making most if not all provisions that were "smart" for rotating media largely meaningless, and the size of rotating media increased so much that the "around the middle of the filesystem" has been a largely moving target. The "default" settings (including the placement of the $MFT on cluster 786432 or 0xC0000 if you prefer) is clearly something that made a lot of sense on a given size of volume, but having it "hardcoded" as default for any volume larger than around 5/6 GB makes not any real sense, hence I stand by my "queer". As seen in the given reference, it is possible (and relatively easy) to "move" the $MFT (and other NTFS filesystem structures) to an "earlier" address on the volume, and the NTFS (which as said has been very, very well designed) works and performs just fine. On the other hand, moving it near the actual "around middle" (on rotating disks) is far from being easy, even nowadays. What I was pointing out is that after all these years the "format" tool has not evolved allowing directly these kind of changes/offering the user the possibility to finer tune the file system.