On 2/7/07, Keech Angelo Famorca <[EMAIL PROTECTED]> wrote: Yumyum. Ill cough out something. linux may be ahead in performance but not in filesystem. What advanced feature of the filesystem that linux is advanced of? having more filesystems that all do the same thing with varying degress of data loss and corruption? that's not advancement for me.
fyi, both soft updates and journalling __does_not_guarantee__ that _no_data_will_be_lost_. =D
and for speed, not all cases linux is beyond. i've tested this both on NetBSD (without softupdates) and gentoo linux (ext3) on the same machine. $ time tar xzf $ time cp -R my-large-collection my-large-collection-2 Result: NetBSD: 11.22s - 29.41s linux: 18.32s - 38.42s you are welcome to test it too.
=D look, you can't just tweak the filesystem on the other and then leave the other on its default! you also have to disable the equivalent feature on Ext3 (journalling). =D please do bother to state if both OS are loaded on the same or identical machines. if you're only using a single machine, then they should have at least identical disks (but not on multi boot), partitions, etc. you should also state the version of the OS (or kernel) that you're testing. i really don't care which FS performs better on your tests, as long as you're going to do it properly. and please do bother to use the typical micro and "real world" testing tools such as Bonnie++, IOZone, etc.
linux has many filesystem, none of them actually appear to be stable, especially during very heavy loads. bsd doesn't want many filesystems that all do the same thing, only with different sets of problems. and looking at the changelog, http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.17-rc4 [XFS] Fix a possible metadata buffer (AGFL) refcount leak when fixing an AG freelist [XFS] Fix a project quota space accounting leak on rename. [XFS] Fix a possible forced shutdown due to mishandling write barriers with remount,ro http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.17-rc6 [PATCH] ext3 resize: fix double unlock_super() so this is what you called stable?
=D and you were reading the changelog of the release candidates =D seriously speaking, with the upstream development of the linux kernel, the sysad who's after the stability instead of the new feature or improved performance, usually waits for the x.x.2x.x or x.x.3x.x release versions. not all filesystems does the same thing. each have their own design and merit that can be applied best for a specific application or based on the available resources.
i don't believe in benchmarks either, i want to prove it by myself. fefe's benchmark is one example of such tests. heck, he even asked the openbsd mailing list on "how to fine-tune openbsd" AFTER publishing the benchmark. he benchmarked a system he really doesn't know.
in benchmarking, test setups are done using the default configuration and then using the optimized configuration. it is common to ask for the expertise of product developers in order to do justice and to prevent any bias. if you read one of the recent papers on Usenix, the researchers also sought the expertise of the *BSD community on one of their FS tests. as of the moment, the most recent micro/real world benchmark was presented on LK 2006 featuring various OS and filesystems: http://bulk.fefe.de/lk2006/talk.pdf as you can see *BSDs also performed well and similar(?) findings can be found here based on a real world benchmark (2005) : http://software.newsforge.com/software/04/12/27/1243207.shtml?tid=72&tid=29 benchmark data may or may not mean anything to an individual especially when the real world application doesn't apply to his/her current setup. and the fact, that even the tools output are inconsistent with each other. "Filesystem performance has many aspects. No single metric for quantifying it" -- Kris Kennaway, Filesystem Performance on FreeBSD BSDCan 2006 http://www.bsdcan.org/2006/papers/FilesystemPerformance.pdf . _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Read the Guidelines: http://linux.org.ph/lists Searchable Archives: http://archives.free.net.ph
