lkml.org 
[lkml]   [2003]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [benchmarks] various filesystems on 2.5.68
From
Date
rwhron@earthlink.net writes:

> mount options
> mount -t ext2 -o defaults,noatime /dev/sdc1 /fs1
> mount -t ext3 -o defaults,noatime,data=writeback /dev/sdc1 /fs1
> mount -t reiserfs -o defaults,noatime /dev/sdc1 /fs1
> mount -t jfs -o defaults,noatime /dev/sdc1 /fs1
> mount -t xfs -o logbufs=8,logbsize=32768,noatime /dev/sdc1 /fs1
>
> mkfs command
> mke2fs -q /dev/sdc1
> mke2fs -q -j -J size=400 /dev/sdc1
> yes "y" | mkreiserfs /dev/sdc1 >/tmp/mkr.out 2>&1
> jfs_mkfs -q /dev/sdc1
> mkfs.xfs -l size=32768b -f /dev/sdc1
>
> Very recent version of xfsprogs/jfsutils/reiserfsprogs/e2fsprogs.
>
> XFS mount/mkfs options came from the XFS FAQ and are very desireable
> for these tests based on an earlier run without them. If anyone

It's my experience too that XFS often performs badly with the default
mkfs/mount options, especially for metadata intensive workloads. The
drawback is that it eats memory. I've been thinking about making it
set the bigger mount option by default based on the available physical
memory; this would probably help a lot of users.

iirc one drawback is that it eats from the vmalloc area which is only 64MB
by default on 32bit. But still should not be that big an issue. On 64bit
it's not an issue at all of course.

Of course the log size cannot be changed this way, but perhaps the default
in mkfs is just too small for today's disk sizes?

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.025 / U:0.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site