On Tue, 19 May 2009, Dave wrote:
Paul B. Henson wrote:
I was checking with Sun support regarding this issue, and they say "The CR
currently has a high priority and the fix is understood. However, there is
no eta, workaround, nor IDR."
If it's a high priority, and it's known how to fix it, I was curious as to
why has there been no progress? As I understand, if a failure of the log
device occurs while the pool is active, it automatically switches back to
an embedded pool log. It seems removal would be as simple as following the
failure path to an embedded log, and then update the pool metadata to
remove the log device. Is it more complicated than that? We're about to do
some testing with slogs, and it would make me a lot more comfortable to
deploy one in production if there was a backout plan :)...
If you don't have mirrored slogs and the slog fails, you may lose any data
that was in a txg group waiting to be committed to the main pool vdevs - you
will never know if you lost any data or not.
No, you won't loose any data.
The issue is that if you export the pool currently you won't be able to
import it with a broken log device. But while a pool is up and its slog
device fails it won't loose any data.
--
Robert Milkowski
http://milek.blogspot.com
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
