How does logical file system overhead relate to file fragmentation?
To retrieve a portion of a file that is contiguous, the OS/app will need to request the file to be opened, and the part it needs. Barring various optimizations, the OS will need to start looking for the file starting at the root, traversing down the directories, with at least some in-memory activity at each level. Then, once it gets to the file's location, verifies permissions and all, then reads some offset.
Now, if the file has many fragments, it must instead look through a list (or tree) of parts of the file to find the location of the offset the program is looking for. I'm not sure about NTFS for this particular case, but some FSes also allow fragmented directory listings, adding another level of looking through a list, or searching a tree.
The process for writing is not merely a reverse, either. A new location for data needs to be found (if there's room), and the new data written, potentially fragmenting the file more. There is also a speed hit with keeping the journal up to date with many writes.
Until now, the many-ms seek times of HDDs represented a
far greater overhead. With <0.3ms seeks, whether a fragment is at one end or the other of the disk's address range doesn't matter. Also, most users don't tend to get enough fragmentation to worry about it, these days, even on HDDs. If MS were to, in the near-future Windows, add a method to prevent or handle only severely fragmented files only (I've had game saves with thousands of fragments, FI--WTF!), which they should have done already, instead of rely on a crutch (diskkeeper), NTFS would be just fine for many more years to come.
Now will performance be less than ideal when you have a file split into more blocks than it physically requires on your SSD? Yes. Is defragging going to fix that? It could improve it, as long as it randomly hits that middle ground where the file is split evenly across the NAND channels. But it could also take things too far and put the entire file on a single NAND channel, which is probably worse.
That's a problem for the firmware devs to handle, and they seem to be doing a good job at it, over-all. They see those physical blocks, and the OS guys don't. Outside of price-sensitive proprietary embedded systems, that is how it should be. Windows
can't put it anywhere specific on the physical flash, and that's not a bad thing.
With NCQ, all overhead except for the software-level overhead will generally be quite small. When that isn't true, you probably don't need a single consumer SSD for your work.