| |||||||||||||
|
| |||||||||||||
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (DebianFilesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (DebianPosted Apr 26, 2006 23:36 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246)In reply to: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian by nix Parent article: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration)
Hmmm.... I must be mistaken. I remember seeing some change notes awhile back (around 3.4) saying that they somehow "fixed" the fragmentation issue. And it seemed (and maybe I was wrong) like it was preallocating the file.
Honestly, that's the sanest thing to do. It makes no sense to start downloading a huge torrent if you don't have the disk space. Maybe I'll submit a patch.... if I can be bothered to learn Python.
(I tried looking through the code for BitTorrent, and quite frankly, it could use some documentation.)
(Log in to post comments)
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Posted Apr 27, 2006 6:32 UTC (Thu) by nix (subscriber, #2304) [Link] Hm, you're right, it has changed, I was out of date.
It looks like the official client preallocates in chunks, so that when it receives a block at offset N where N is greater than any previously received block offset in the file, it preallocates up to N but not after it.
Azureus (a much more popular client by all accounts, and where a lot of de facto protocol development seems to be going on) doesn't preallocate.
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Posted Apr 28, 2006 23:38 UTC (Fri) by dirtyepic (subscriber, #30178) [Link] No, Azureus has offered all three methods - sparse, preallocate, and incremental - as a user configurable option for years now (at least before 2003).
|
|
||||||||||||