Normally, MLdonkey creates a temporary file for each download immediately upon its addition to the download queue; the size of this temporary file equals to the size of the download. If the partition where temporary files are located doesn't support sparse files, the corresponding amount of disk space will be allocated immediately, thus rendering it unavailable for any other use. For instance, an attempt to download 10 files of 1 Gb each will lead to the decrease of free space on the temporary partition by 10 Gb right away, despite the fact that no single byte of useful data has been transferred yet; if the said partition had native sparse files support, such a sharp drop wouldn't have happened, and the space would've been allocated block by block only as data started pouring in.
In the former case, enabling emulate_sparsefiles would similarily eliminate the spike in disk space usage. Instead of creating a single temp file for each download, MLdonkey will create part files in the temporary directory, adding more of them as needed, and glue them together into a proper output file as download completes. Such behavior could be observed in many other P2P clients, such as eDonkey2000.
Please note that there's little to no sense in enabling this option on filesystems with native sparse files support (NTFS v. 5.0 and all of Linux/UNIX based filesystems).
> set emulate_sparsefiles true
emulate_sparsefiles is an experimental feature. There have been horror stories involving it, so think twice before enabling it.
Since there have been bad reports when this feature is enabled (Invalid_argument "Unix.write" exceptions...), it has been disabled in 2.8.0.
_I don't know about Linux NTFS support, but under Windows, while NTFS does support sparse files, it's not the default behavior and must be enabled on a file basis. See
To my understanding, emulate_sparsefiles enables _emulation_ of sparsefiles, i.e. makes the core to use multiple tempfiles instead of a normal continuous one. To provide the functionality described in paragraph above, there should be _two_ separate and distinct options - \"enable_sparsefiles\" and \"emulate_sparsefiles\", so 3 possible combinations can be achieved: 1) continous regular files are used, 2) continous sparse files are used, if possible, 3) multiple temp-files are used for chunks.
_What I meant, about your note, is that emulate_sparsefiles may still make sense under Windows, even with NTFS 5._ %%% _From what I've read, recent Linux 2.6 kernels support sparse files on NTFS; And probably the Unix way (sparse files are created without any preliminary action). The later needs checking, however. Good luck :)_ %%% _Now, what would be the point of not using sparse files when they're available (enable_sparsefiles = false) ? Keep fragmentation at the minimum ? Confuse even more users ? ;)_
Roger that, to a) keep fragmentation minimal and b) to guarantee that there is enough space to complete _all_ the downloads currently in the queue. Personally, I would prefer to use \"enable_sparsefiles = false\" on NTFS, if I ever decide to run MLdonkey on Windows. :)