FreeBSD's UFS vs Ext4

George Liaskos geo.liaskos at gmail.com
Tue Feb 9 10:38:00 UTC 2010


For what is worth these are the results on my Lenovo Thinkpad T500 with zfs.
http://global.phoronix-test-suite.com/?k=profile&u=thuglife-5875-16786-4629

> dmesg | grep  ada0
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <WDC WD2500BEKT-00A25T0 01.01A01> ATA-8 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes)
ada0: Command Queueing enabled
ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C)

zfs prefetch off
zfs checksum on | fletcher4
zfs compression on | lzjb

vfs.zfs.arc_min="64M"
vfs.zfs.arc_max="512M"

stock ufs FBSD
http://www.phoronix.com/scan.php?page=article&item=linux_bsd_opensolaris&num=6

Apples and oranges, I know, the point is I don’t feel that the IO
performance is lagging on my laptop.

On Tue, Feb 9, 2010 at 9:33 AM, krad <kraduk at googlemail.com> wrote:
> On 9 February 2010 01:54, J65nko <j65nko at gmail.com> wrote:
>
>> On Mon, Feb 8, 2010 at 5:46 AM, alex <alex at mailinglist.ahhyes.net> wrote:
>>
>>
>> > I do suspect personally that the ext4 filesystem is the reason for the
>> > difference here, since ext4 has a number of features such as deferred
>> disk
>> > writes etc. Even deleting a large file off that raid array I can see a
>> > difference, prior to reformatting, i deleted a 190GB file off the raid,
>> > under UFS the delete took quite some time (well over 10 seconds), under
>> ext4
>> > the deletion of the same size file took about 3 seconds.
>> >
>> > But what I said with ext4 being faster then the aging UFS still rings
>> true
>> > in my mind, look at the recent Phoronix benchmarks for yourself and see
>> (10
>> > pages of benchmarks).
>> >
>> >
>> http://www.phoronix.com/scan.php?page=article&item=freebsd8_benchmarks&num=1
>> > (skip to page 7 of the benchmarks if you want to see the I/O stuff
>> relating
>> > to disk performance)
>>
>> According to the first page they used the default configuration of all
>> benchmarked OS'es.
>> And what is the default mount option on Linux "async"
>>
>> The FreeBSD man page for mount describes this "async" option as follows:
>>
>> async   All I/O to the file system should be done asynchronously.
>>        This is a dangerous flag to set, since it does not guar-
>>        antee that the file system structure on the disk will
>>        remain consistent.  For this reason, the async flag
>>        should be used sparingly, and only when some data recov-
>>        ery mechanism is present.
>>
>>
>> The OpenBSD man page has the following additional remark:
>>
>>        The most common use of this flag is to speed up
>>        restore(8) where it can give a factor of two speed in-
>>        crease.
>>
>> Conclusion: you cannot compare filesystem performance, when you give
>> one a unfair speed advantage of what could be a factor two.
>> _______________________________________________
>> freebsd-questions at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>> To unsubscribe, send any mail to "
>> freebsd-questions-unsubscribe at freebsd.org"
>>
>
>
> you are of course entirely correct, however one of the goals of more modern
> file systems eg ext4 is to make async safe to use, because of this speed up.
> At the end of the day faster is faster simple as. Having said that it would
> be nice to see a gjournaled ufs system for comparison, as well as zfs
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>


More information about the freebsd-questions mailing list