Carson Gaspar wrote:
Miles Nordin wrote:
"re" == Richard Elling <richard.ell...@gmail.com> writes:
How do you handle the case when a hotplug SATA drive is powered off
unexpectedly with data in its write cache? Do you replay the writes,
or do they go down the ZFS hotplug write hole?
If zfs never got a positive response to a cache flush, that data is
still in memory and will be re-written. Unless I greatly misunderstand
how ZFS works...
If the drive _lies_ about a cache flush, you're screwed (well, you can
probably roll back a few TXGs...). Don't buy broken drives / bridge
chipsets.
Hrm... thinking about this some more, I'm not sure what happens if the
drive comes _back_ after a power loss, quickly enough that ZFS is never
told about the disappearance (assuming that can happen without a human
cfgadm'ing it back online - I don't know).
Does anyone who understands the internals better than care to take a
stab at what happens if:
- ZFS writes data to /dev/foo
- /dev/foo looses power and the data from the above write, not yet
flushed to rust (say a field tech pulls the wrong drive...)
- /dev/foo powers back on (field tech quickly goes whoops and plugs it
back in)
In the case of a redundant zpool config, when will ZFS notice the
uberblocks are out of sync and repair? If this is a non-redundant zpool,
how does the response differ?
--
Carson
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
