2012-01-08 5:45, Richard Elling wrote:
I think you will see a tradeoff on the read side of the mixed read/write
Sync writes have higher priority than reads so the order of I/O sent to the disk
will appear to be very random and not significantly coalesced. This is the
pathological worst case workload for a HDD.
I guess this is what I'm trying to combat when thinking
about a dedicated ZIL (SLOG device) in ordedr to reduce
pool's fragmentation. It is my understanding (which may
be wrong and often is) that without a dedicated SLOG:
1) Sync writes will land on disk randomly into nearest
(to disk heads) available blocks, in order to have them
2) Coalesced writes (at TXG sync) may have intermixed
data and metadata blocks, of which metadata may soon
expire due to whatever updates, snapshots or deletions
involving the blocks this metadata references.
If this is true, then after a while there will be many
"available" cheese-holes from expired metadata among
larger data blocks.
3) Now, this might be further complicated (or relieved)
if the metadata blocks are stored in separate groupings
from the "bulk" user-data, which I don't know about yet.
In that case it would be easier for ZFS to prefetch
metadata from disk in one IO (as we discussed in another
thread), as well as to effectively reuse the small
cheese-holes from freed older metadata blocks.
If any of the above is true, then it is my "blind
expectation" that a dedicated ZIL/SLOG area would
decrease fragmentation at least due to sync writes
of metadata, and possibly of data, into nearest
HDD locations. Again, this is based on my possibly
wrong understanding that the blocks committed to a
SLOG would be neatly recommitted to the main pool
during a TXG close with coalesced writes.
I do understand the argument that if the SLOG is
dedicated from a certain area on the same HDD, then
in fact this would be slowing down the writes by
creating more random IO and extra seeks.
But as a trade-off I hope for more linear faster
reads, including pool import, scrubbing and ZDB
walks; and less fragmented free space.
Is there any truth to these words? ;)
zfs-discuss mailing list