| |||||||||||||
|
| |||||||||||||
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (DebianFilesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (DebianPosted Apr 26, 2006 12:39 UTC (Wed) by nix (subscriber, #2304)In reply to: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration) by drag Parent article: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration)
Indeed. And then there are nasty worst-cases like BitTorrent clients (allocate vast nearly empty sparse file, then fill up blocks of it in random order all the while reading the ones you previously wrote)...
(Log in to post comments)
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Posted Apr 26, 2006 13:49 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] I am pretty sure current versions of official BitTorrent client put down a large, empty file now instead of filling a sparse file, specifically to avoid the nasty fragmentation effects you mention. In fact, I think that's been true for a couple years now.
Obviously, other clients may not do this. If they do, I'd say file a bug report. Sparse files are good for files that will tend to remain sparse. They make no sense for the kinds of files you'd tend to download w/ BT. After all, you need the disk space to store the file you're downloading, so you may as well allocate it up front.
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Posted Apr 26, 2006 21:45 UTC (Wed) by nix (subscriber, #2304) [Link] The official bittorrent client and Azureus both work sparsely. After all, unless you make an effort to fill a file with content, sparseness is pretty much the default...
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Posted Apr 26, 2006 23:36 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] 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.)
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).
|
|
||||||||||||