On Fri, 19 Mar 2021, Kent Watsen wrote:
HI Bob,
The ARC is a "hot" cache. The data might be updated a million times before it
is actually written to underlying store. If data is in the ARC, then it is not read from
the persistent store.
That’s what I was hoping, but I’m surprised by the “update a million
times before it’s written” comment. Does the comment apply only to
async-writes? Assuming async-writes are flushed every, e.g., 5
secs, would the “million updates" need to occur in that window?
Yes, exactly. Synchronous writes do need to be persisted.
Asynchronous writes only need to be consistent.
Once the ARC is warmed up, does the ARC-cached part of the
filesystem then move at the speed of RAM (e.g., with the illusion of
massive IOPS), regardless the underlying pool topology? So "mirror
vs. raidz" and "SSD vs. HDD” decisions should be primarily focused
on supporting the cache-miss and sync-writes cases? (excluding the
"large-stream" case as such likely won’t cause ARC-evictions)
Yes, this is the primary purpose of the ARC cache. In addition to
concerns about performance when actual reads/writes need to happen,
there should be some concern about space efficiency. For example,
disks with 4k sectors are less space efficient with raidz than ones
with 512 byte sectors, and particularly if small zfs filesystem block
sizes are used.
Bob
--
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
------------------------------------------
illumos: illumos-discuss
Permalink:
https://illumos.topicbox.com/groups/discuss/T4a93ce1686bc673e-M3489703133f4199f9077e53f
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
