Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 May 2009 06:50:05 +0100
From:      Matthew Seaman <m.seaman@infracaninophile.co.uk>
To:        Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl>
Cc:        Gary Gatten <Ggatten@waddell.com>, freebsd-questions@freebsd.org
Subject:   Re: FreeBSD & Software RAID
Message-ID:  <4A1CD48D.3020900@infracaninophile.co.uk>
In-Reply-To: <alpine.BSF.2.00.0905262119490.47364@wojtek.tensor.gdynia.pl>
References:  <4A1AA3DC.5020300@network-i.net> <200905261238.52979.kirk@strauser.com> <70C0964126D66F458E688618E1CD008A0793ED91@WADPEXV0.waddell.com> <4A1C3725.8040509@infracaninophile.co.uk> <alpine.BSF.2.00.0905262119490.47364@wojtek.tensor.gdynia.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6C7345295952FAF2B6E90806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Wojciech Puchar wrote:
>> You can make ZFS work on i386, but it requires very careful tuning and=
=20
>> is not
>> going to work brilliantly well for particularly large or high-throughp=
ut
>> filesystems.
>=20
> you mean "high transfer" like reading/writing huge files. anyway not=20
> faster than properly configured UFS+maybe gstripe/gmirror.

I mean high-throughput, as in bytes-per-second.  Whether that consists of=
 a
very large number of small files or fewer larger ones is pretty much imma=
terial.
=20
> for small files it's only fast when they will fit in cache, same with U=
FS

For any files, it's a lot faster when they can be served out of cache.  T=
hat's
true for any filesystem.  It's only when you get beyond the capacity of y=
our
caches that things get interesting.

I really don't have any hard data on ZFS performance relative to UFS + ge=
om.
However my feeling is that UFS will win at small scales, but that ZFS wil=
l
close the gap as the scale increases, and that ZFS is the clear winner wh=
en
you consider things other than direct performance -- manageability, resil=
ience
to hardware failure or disk errors, etc.  Of course, "small scale" (ie. a=
bout
the same size as a single drive) is hundreds of GB nowadays, and growing.=


	Cheers,

	Matthew

--=20
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW


--------------enig6C7345295952FAF2B6E90806
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkoc1JMACgkQ8Mjk52CukIwCtQCdEJGze4VTIkJwPCcYR6zRGHM2
y1QAn2v7dzHaCViW2gAQFRz1KI8bbRA+
=dLDk
-----END PGP SIGNATURE-----

--------------enig6C7345295952FAF2B6E90806--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A1CD48D.3020900>