Robert Milkowski wrote On 02/06/07 11:43,:
Hello eric,
Tuesday, February 6, 2007, 5:55:23 PM, you wrote:
IIRC Bill posted here some tie ago saying the problem with write cache
on the arrays is being worked on.
ek> Yep, the bug is:
ek> 6462690 sd driver should set SYNC_NV bit when issuing SYNCHRONIZE
ek> CACHE to
ek> SBC-2 devices
Thanks. I see a workaround there (I saw it earlier but it doesn't
apply to 3510) and I have a question - setting zil_disable to 1
won't actually completely disable cache flushing, right? (still every
txg group completes cache would be flushed)??
ek> We have a case going through PSARC that will make things works
ek> correctly with regards to flushing the write cache and non-volatile
ek> caches.
There's actually a tunable to disable cache flushes:
zfs_nocacheflush and in older code (like S10U3) it's zil_noflush.
Yes, but we didn't want to publicise this internal switch. (I would
not call it a tunable). We (or at least I) are regretting publicising
zil_disable, but using zfs_nocacheflush is worse. If the device is
volatile then we can get pool corruption. An uberblock could get written
before all of its tree.
Note, zfs_nocacheflush and zil_noflush are not the same.
Setting zil_noflush stopped zil flushes of the write cache, whereas
zfs_nocacheflush will additionally stop flushing for txgs.
Hmmmm...
ek> The tricky part is getting vendors to actually support SYNC_NV bit.
ek> If you your favorite vendor/array doesn't support it, feel free to
ek> give them a call...
Is there any work being done to ensure/check that all arrays Sun sells
do support it?
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
