[Deepak asks about testing XFS performance using NFS V2/V3 and a standard
NFS benchmark such as SFS 3.0.]
Unfortunately, the performance of any version of NFS, either V3 or V2, will
totally mask the performance of XFS. When used as a local filesystem on a
system which has the capability of doing substantial I/O, the performance of
XFS can be quite dramatic. (Read: multiple gigabytes per second, no problem
at all.)
Note that the available performance in typical NAS (network-attached
storage) is *not* up to the performance levels that XFS can support. Think
of a system with, oh, 32 or 64 independent PCI buses each with fast
FibreChannel controllers attached to fast disk arrays. The performance
issues with NAS have to do with the overhead and performance of current
network stacks vs. disk drivers.
If you run standard NFS benchmarks, the performance differences between XFS
and other filesystems will be masked not only by your NAS, but even more so
by NFS performance and overhead (watch your CPU utilization go to 100%). The
very nature of the benchmarks is also not conducive to showing off just how
fast XFS can be. These benchmarks work with tiny files and filesystems (tiny
from XFS's perspective), small directories, and a relatively high ratio of
directory operations to actual I/O ops.
XFS was designed to deal with large files, directories with huge numbers of
files, and to provide exceptional performance in these domains. Its
performance with small files and small directories is typically in the same
ball-park as other filesystems. Sometimes, XFS can be faster with
"conventional" loads - use it as your /tmp filesystem, and it'll rarely
actually write to disk, or look at xfsdump performance vs. "regular" dump
performance to a high-speed tape subsystem, for example. Of course, the data
integrity and crash-recovery provided by XFS will be significantly better
what non-journalled filesystems and filesystems with less "field experience"
provide.
--Geoff Peck geoff@peck.com
[Note: I'm not a reader of this list, but happened to chance across Deepak's
posting, so I'm answering it here.]
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org