On Aug 1, 2006, at 14:18, Torrey McMahon wrote:
(I hate when I hit the Send button when trying to change windows....)
Eric Schrock wrote:
On Tue, Aug 01, 2006 at 01:31:22PM -0400, Torrey McMahon wrote:
The correct comparison is done when all the factors are taken
into account. Making blanket statements like, "ZFS & JBODs are
always ideal" or "ZFS on top of a raid controller is a bad idea"
or "SATA drives are good enough" without taking into account the
amount of data, access patterns, numbers of hosts, price,
performance, data retention policies, audit requirements ... is
where I take issue.
Then how are blanket statements like:
"That said a 3510 with a raid controller is going to blow the
door, drive brackets, and skin off a JBOD in raw performance."
Not offensive as well?
Who said anything about offensive? I just said I take issue such
statements in the general sense of trying to compare boxes to boxes
or when making blanket statements such as "X always works better on
Y".
The specific question was around a 3510JBOD having better
performance then a 3510 with a raid controller. Thats where I said
the raid controller performance was going to be better.
just to be clear .. we're talking about a 3510 JBOD with ZFS (i guess
you could run pass through on the controller or just fail the
batteries on the cache) vs a 3510 with the raid controller turned
on .. I'd tend to agree with Torrey, mainly since well designed RAID
controllers will generally do a better job with their own back-end on
aligning I/O for efficient full-stripe commits .. without battery
backed memory on the host, CoW is still going to need synchronous I/O
somewhere for guaranteed writes - and there's a fraction of your gain.
Don't get me wrong .. CoW is key for a lot of the cool features and
amazing functionality in ZFS and I like it .. it's just not generally
considered a high performance I/O technique for many cases when we're
talking about committing bits to spinning rust. And while it may be
great for asynchronous behaviour, unless we want to reveal some
amazing discovery that reverses years of I/O development - it seems
to me that when we fall to synchronous behaviour the invalidation of
the filesystem's page cache will always play a factor in the overall
reduction of throughput. OK .. I can see that we can eliminate the
read/modify/write penalty and write hole problem at the storage
layer .. but so does "battery backed" array cache with the real
limiting factor ultimately being the latency between the cache
through the back-end loops to the spinning disk. (I would argue that
low cache latency and under-saturated drive channels matter more than
the sheer amount of coherent cache)
Speaking in high generalities, the problem almost always works it's
way down to how well an array solution balances properly aligned I/O
with the response time between cache across the back-end loops to the
spindles and any inherent latency there or in between. OK .. I can
see that ZFS is a nice arbitrator and is working it's way into some
of the drive mechanics, but there is still some reliance on the
driver stack for determining the proper transport saturation and back-
off. And great - we're making more inroads with transaction groups
and an intent log that's wonderful .. and we've done a lot of cool
things along the way .. maybe by the time we're done we can move the
code to a minimized Solaris build on dedicated hardware .. and build
an array solution (with a built in filesystem) .. that's big .. and
round .. and rolls fast .. and then we can call it .. (thump thump
thump) .. the zwheel :)
---
.je
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
