| |||||||||||||
|
| |||||||||||||
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration)Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration)Posted Apr 26, 2006 11:36 UTC (Wed) by drag (subscriber, #31333)In reply to: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration) by malefic Parent article: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration)
Exactly..
And this paticular article is worse then most. It's quite a arrogent suggestion that a person can, in a short article, provide more accurate results then years of benchmarking and study.
I mean that it's fine to make something like this pointing out your personal results... but I don't see a single aspect of this benchmark that provides any sort of real world results.
Even a big file copy isn't so hot.. in a desktop environment you'd have a lot of little file accesses going on and scedualing issues and such all the time. How does various file systems respond to those situations, for example?
It's not that realistic.
It seems that benchmarks can only provide usefull data on one specific situation. You aren't going to be able to determine what is the 'best' overall file system without messing around with many different types of hardware and system loads. Mixing different benchmark tests.. It would take weeks and cost much more money then I'd be willing to spend. And even then a kernel revision may change all that if somebody figures out a fix for a bottleneck or drive controller driver or something like that.
Personally I aim for most reliable. All the system perform close enough that it doesn't matter much, performance wise, what you choose. At least thats what it seems to me. Right now it seems that, at least on commodity hardware, ext3 wins in my book. Although XFS has some very nice aspects to it.
(Log in to post comments)
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Posted Apr 26, 2006 12:39 UTC (Wed) by nix (subscriber, #2304) [Link] 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)...
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).
|
|
||||||||||||