Gregory Shaw writes:
> Rich, correct me if I'm wrong, but here's the scenario I was thinking
> of:
>
> - A large file is created.
> - Over time, the file grows and shrinks.
>
> The anticipated layout on disk due to this is that extents are
> allocated as the file changes. The extents may or may not be on
> multiple spindles.
>
> I envision a fragmentation over time that will cause sequential
> access to jump all over the place. If you use smart controllers or
> disks with read caching, their use of stripes and read-ahead (if
> enabled) could cause performance to be bad.
>
> So, my thought was to de-fragment the file to make it more contiguous
> and to allow hardware read-ahead to be effective.
>
> An additional benefit would be to spread it across multiple spindles
> in a contiguous fashion, such as:
>
> disk0: 32mb
> disk1: 32mb
> disk2: 32mb
> ... etc.
>
> Perhaps this is unnecessary. I'm simply trying to grasp the long
> term performance implications of COW data.
>
And my take is that, if I spread the 128K block all over but
read then sufficiently ahead (say 2MB) then I shall be very
much OK from the performance standpoint.
Actually I just ran this (8M reads) and am getting pretty
good numbers (single disk pool):
[EMAIL PROTECTED](44): zpool iostat 1
capacity operations bandwidth
pool used avail read write read write
---------- ----- ----- ----- ----- ----- -----
zfs 24.4G 9.38G 0 0 59.5K 42
zfs 24.4G 9.38G 496 0 62.1M 0
zfs 24.4G 9.38G 497 0 62.1M 0
zfs 24.4G 9.38G 496 0 62.0M 0
zfs 24.4G 9.38G 496 0 62.0M 0
zfs 24.4G 9.38G 497 0 62.1M 0
zfs 24.4G 9.38G 493 0 61.6M 0
zfs 24.4G 9.38G 491 0 61.4M 0
zfs 24.4G 9.38G 492 0 61.5M 0
zfs 24.4G 9.38G 485 0 60.6M 0
So what benefit do you see from relaying-out the file, is it
just performance, or something else ?
One benefit that ZFS gets out of working with smaller chunks
is that everytime one I/O completes then ZFS can decide
which of the in-kernel queue ZIO has the highest
priority. If you swamp a disk with a ton of very large I/Os;
they will take more time to complete and high priority ones
that show up in-between will just have to wait more.
-r
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
