For Output ops, ZFS could setup a 10MB I/O transfer to disk
starting at sector X, or chunk that up in 128K while still
assigning the same range of disk blocks for the
operations. Yes there will be more control information going
around, a little more CPU consumed, but the disk will be
streaming all right, I would guess.
Most heavy output load will behave this way with ZFS, random
or not. The throughput will depend more on the availability
of contiguous chunk of disk blocks that the actual record
size in use.
As for random input, the issue is that ZFS does not get a
say as to what the application is requesting in terms of
size and location. Yes doing a 4M Input of contiguous disk
block will be faster than random reading 128K chunks spread
out. But if the application is manipulating 4M objects,
those will stream out and land on contiguous disk blocks (if
available) and those should stream in as well (if our read
codepath is clever enough).
The fundamental question is really, is there something that
ZFS does that causes data that represents an application
logical unit of information (likely to be read as one chunk)
and so that we would like to have contiguous on disk, to
actually spread out everywhere on the platter.
-r
Richard Elling writes:
> billtodd wrote:
> > I do want to comment on the observation that "enough concurrent 128K I/O
> > can
> > saturate a disk" - the apparent implication being that one could therefore
> > do
> > no better with larger accesses, an incorrect conclusion. Current disks
> > can
> > stream out 128 KB in 1.5 - 3 ms., while taking 5.5 - 12.5 ms. for the
> > average-seek-plus-partial-rotation required to get to that 128 KB in the
> > first
> > place. Thus on a full drive serial random accesses to 128 KB chunks will
> > yield
> > only about 20% of the drive's streaming capability (by contrast, accessing
> > data using serial random accesses in 4 MB contiguous chunks achieves
> > around
> > 90% of a drive's streaming capability): one can do better on disks that
> > support queuing if one allows queues to form, but this trades
> > significantly
> > increased average operation latency for the increase in throughput (and
> > said
> > increase still falls far short of the 90% utilization one could achieve
> > using
> > 4 MB chunking).
> >
> > Enough concurrent 0.5 KB I/O can also saturate a disk, after all - but
> > this
> > says little about effective utilization.
>
> I think I can summarize where we are at on this.
>
> This is the classic big-{packet|block|$-line|bikini} versus
> small-{packet|block|$-line|bikini} argument. One size won't fit all.
>
> The jury is still out on what all of this means for any given application.
> -- richard
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
