MC have no control where the filesystem write the data. MC just write data and the filesystem find some where to put the data.
If you get 33 fragments for a 7MB file then I guess your drive is very fragmented or very full. If you have a SSD, the fragments does not matter.
What I am talking about is mechanical Hard disk, not SSD, fragmentation has almost no effect on SSD. Also I got 20GB free space when my 160GB hard disk write that 7MB file.
There is no differers from synchronous and asynchronous in how the system write the file. the different is that with asynchronous mode the file is copied by reading and writing at the same time and should only be used if the source and target are totally different drives.
Chunk size + sync/async mode of writing does affect fragmentation. In async mode, data read and write on different devices. The moment, when a piece data is being read from one hard disk, that piece of data cannot be written on other hard disk at the same time because it is still being read. In a fast rotating Hard disk, the hard disk head hence misses the consecutive write sequence because it has to wait until that piece of data finished reading. Filesystem can only find other empty place to write that piece of data when it finished reading it, and that causes fragmentation.
In Sync mode, by reading the whole file, or a big chunk of data into memory, and then write it back in a single time, this can help reducing fragmentation as filesystem now writes a big chunk of data without interleaving reading and writing.
Not sure what you mean by that. but how many fragmentation a files gets have nothing to do with how many times you read it.
I mean, on mechanical hard disk, reducing fragmentation helps faster booting and loading files because program files are usually read many times during system uptime. If you copy some program files from one place to another, you would try to keep them 1 fragment per file as possible.
In "total commander" and "fastcopy", I can set both the buffer and chunk (I/O) size to 16MB or more instead of only 1MB maximum and I can always get 1 fragment per file with them. I hope I can also set maximum chunk size to 16MB or more in MC.
Hope you understand my poor English.
I do not think sync / async really matters for fragmentation, since the filesystem do not know the location of the drive head.
The filesystem do not search for free block on the disk while writing. (That would be very very slow), Simplified they have an in memory database of what filesystem blocks are free and so. The filesystem might be located on a raid system and then you can have 10 drive heads depending on configuration.
The filesystem do not know about the drive layout. It only knows that it can write data from block x to block y.
However you are correct that chunk size matters. because if you have larger chunks there is more chance for the filesystem to find an entire block that the chunk of data fits into. But the filesytem will try to keep the data consistent, however if there a low free space or the drive is fragmented it can be hard for it to find a block right next to the previous block. But fragmentation do not need be super bad. it depends on in what order they are. but less fragment are always good.
Windows will try to auto defrag data when computer are idle and make sure file are consistent. (Not on XP)
However chunck size that is too large is not good for write performance (and IO performance), if you write chunks that are larger the the drive cache the OS driver for the harddrive will have to stall and wait before data can be sent to it.
In MC you can tweak the chunck size. Their is no max limit for chunk size in MC, but there is in the settings UI (bug), so one have to hack the config file to get around that.
But that will fix.
But one think that will make more of a different is the option to preallocate the target file. Most filesystem support that now and that is an option that is coming. This will tell the filesystem before the data is written that the file is for example 100MB, and the filesystem will create an empty 100MB file directly that the data is then written into. (since it gets a hint of the final size the filesystem can find a large enough block range for the entire file directly)
However there are some issues with this on some filesystem and network location so this option will not be on by default.
sync/async is mostly a performance option. when copy between 2 physical drives async is faster. since reads do not need to wait until writes have finished.
there are room for X number of chunks in memory.. and if the buffer is large enough the and writes are slow the buffer can be filled up with the entire file.
