Quicksearch
Disclaimer
The individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.
ZFS cache flush
Thursday, March 1. 2007
Sometimes the standard behaviour of flushing the cache after writing the ZIL to disk hurts your performance more than nescessarry: For example when you have an storage array, that have an battery backed cache. The extra cache flush isnīt really nescessary to ensure data integrity, but hurts the performance on these system: Jason discusses this effect in an older blog entry: Shenanigans with ZFS flushing and intelligent arrays.... Nevertheless itīs an interesting read for everybody using ZFS on intelligent storage.
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
very interesting reading.
But don't forget to read the comment from Matt Ahrens. disabling ZFS to not force the storage cache to flush is in my opinion the right way. There may be, and there suresly are, applications who really do rely on that function. So just tuning the storage to just don't flush on a specific type of OS in any case will lead into ata loss. Certain apps rely on it and may be wrong by just beeing ignored by the storage. What happens if a maintenance application wants to prepare the storage for a shutdown or dismount of a cache controller. Data loss is the result. So having the ZFS (the ZFS host) the decision for just not flushing for himself is the best way. Modern structured operating departements differentiate between storage ops and server ops. Another pitfall...... So please take Matts comments serious
But don't forget to read the comment from Matt Ahrens. disabling ZFS to not force the storage cache to flush is in my opinion the right way. There may be, and there suresly are, applications who really do rely on that function. So just tuning the storage to just don't flush on a specific type of OS in any case will lead into ata loss. Certain apps rely on it and may be wrong by just beeing ignored by the storage. What happens if a maintenance application wants to prepare the storage for a shutdown or dismount of a cache controller. Data loss is the result. So having the ZFS (the ZFS host) the decision for just not flushing for himself is the best way. Modern structured operating departements differentiate between storage ops and server ops. Another pitfall...... So please take Matts comments serious
+1
The LKSF book
The book with the consolidated Less known Solaris Tutorials is available for download here
Web 2.0
Contact
Networking
xing.com
LinkedIn
Facebook
My photos
- mail: joerg@c0t0d0s0.org
- icq: 144000169
- Me, myself and I
- openBC
- My del.icio.us
- c0t0d0s0@twitter
- c0t0d0s0@last.fm
- wiki@c0t0d0s0
- Amazon Wishlist
Networking
xing.com
My photos
Comments
about Nanosecond
Wed, 23.05.2012 00:11
I remember this being drummed
into us during Digital Design
at Uni. It's important to cons
ider it when laying out [...]
Mon, 21.05.2012 18:04
Hello Kevin, Im not surprised
with what you are seeing or ha
ve seen when attaching a SSD t
o a USB2.0. USB3.0 helps [...]
Mon, 21.05.2012 04:44
Hi Greg,
With regards to IO
PS I have seen terrible result
s using a 60GB SATA2 SSD with
USB2.0 - USB2 really cho [...]
about ZFS Dedup Internals
Sat, 19.05.2012 09:50
There is no impact to boot/imp
ort times, as the DDT is loade
d as needed ... so the pool is
imported as fast as wit [...]
Buttons
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Germany License
