Drew Balfour wrote:
Does anyone know why it's "applications" and not "data"?
Perhaps something like:
status: One or more devices has experienced an error. A successful
attempt to
correct the error was made using a replicated copy of the data.
Data on the pool is unaffected.
If it was (successful), that would have been something. It wasn't.
'status' brought up the 'unrecoverable error', whatever number of
'scrub's I did. Toby: 'self-healing' is fine, but that message simply
sounds scary, and worse: it doesn't propose any further sort of action
and its consequences.
"Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'. "
This does sound scary, at least to me. How to 'determine if the device
needs to be replaced'?
Should I 'clear' or 'replace'?
In the end, it needed a 'clear' and that one CKSUM error went away. As
it seems without further consequences and a fully sane disk.
Don't call that 'self-healing'. This is an arcane method demanding
plenty of user activity, interaction, reading-up, etc.
Yes, Richard, you are correct, linguistically. There was an
unrecoverable error in a layer not affecting the layer containing the
data. Telling ZFS to replace some metadata with correct ones resolve the
- probably - non-existent problem. This reminds me of vfat, with its
mirror-FAT. Wouild I want to read about an 'unrecoverable error' when
the mirror is needed? probably not. And if, then I wouldn't want to have
to type 'clear'.
And surely I wouldn't want to wait until I typed 'status' until I am
made aware of the existence of an unrecoverable error, would I!
It seems most in here don't run production servers. A term like
'unrecoverable' sends me into a state of frenzy. It sounds like my
systems are dying any minute. From what I read, it is harmless. Some
redundant metadata could not be retrieved. If this was the case, Toby, I
wouldn't want to have to type anything. I'd rather have the system
detecting the situation on its own accord, trying the redundant metadata
(we do have snapshots, don't we!), and scrub on its very own. At the
end, a mail to root would be in order, informing me that an error has
been corrected and no data compromised at all. Thank you, ZFS!
That's what I'd call 'self-healing' and 21-st century.
Uwe
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
