Hi Robert

I didn't take any offense. :-) I completely agree with you that zpool
striping leverages standard RAID-0 knowledge in that if a device
disappears your RAID group goes poof. That doesn't really require a
notice...was just trying to be complete. :-)

The surprise to me was that detecting block corruption did the same
thing...since most hardware RAID controllers and filesystems do a poor
job of detecting block-level corruption, kernel panicking on corrupt
blocks seems to be what folks like me aren't expecting until it
happens.

Frankly, in about 5 years when ZFS and its concepts are common
knowledge, warning folks about corrupt blocks re-booting your server
would be like notifying them what rm and mv do. However, until then
warning them that corruption will cause a panic would definitely aid
folks who think they understand because they have existing RAID and
SAN knowledge, and then get bitten. Also, I think the zfsassist
program is a great idea for newbies. I'm not sure how often it would
be used by storage pros new to ZFS. Using the gal with the EMC DMX-3
again as an example (sorry! O:-) ), I'm sure she's pretty experienced
and had no problems using ZFS correctly...just was not expecting a
kernel panic on corruption and so was taken by surprise as to what
caused the kernel panic when it happened. A warning message when
creating a striped pool, would in my case have stuck in my brain so
that when the kernel panic happened, corruption of the zpool would
have been on my top 10 things to expect as a cause. Anyway, this is
probably an Emacs/VI argument to some degree. Now that I've
experienced a panic from zpool corruption its on the forefront of my
mind when designing ZFS zpools, and the warning wouldn't do much for
me now. Though I probably would have preferred to learn from a warning
message instead of a panic. :-)

Best Regards,
Jason

On 12/19/06, Robert Milkowski <[EMAIL PROTECTED]> wrote:
Hello Jason,

Tuesday, December 19, 2006, 11:23:56 PM, you wrote:

JJWW> Hi Robert,

JJWW> I don't think its about assuming the admin is an idiot. It happened to
JJWW> me in development and I didn't expect it...I hope I'm not an idiot.
JJWW> :-)

JJWW> Just observing the list, a fair amount of people don't expect it. The
JJWW> likelihood you'll miss this one little bit of very important
JJWW> information in the manual or man page is pretty high. So it would be
JJWW> nice if an informational message appeared saying something like:

JJWW> "INFORMATION: If a member of this striped zpool becomes unavailable or
JJWW> develops corruption, Solaris will kernel panic and reboot to protect
JJWW> your data."

JJWW> I definitely wouldn't require any sort of acknowledgment of this
JJWW> message, such as requiring a "-f" flag to continue.

First sorry for my wording - no offense to anyone was meant.

I don't know it's like changing every tool in system so:

  # rm file
  INFORMATION: by removing file you won't be able to read it again

  # mv fileA fileB
  INFORMATION: by moving fileA to fileB you won't be able ....

  # reboot
  INFORMATION: by rebooting server it won't be up for some time


I don't know such behavior is desired.
If someone don't understand basic RAID concepts then perhaps some
assistant utilities (gui or cli) is more appropriate for them, like
Veritas did. But putting warning messages here and there to inform
user that he probably doesn't know what is he doing isn't a good
option.

Perhaps zpool status should explicitly show stripe groups with word
stripe, like:

   home
     stripe
       c0t0d0
       c0t1d0

So it will be more clear to people what they actually configured.
I would really hate a system informing me on every command that I
possibly don't know what I'm doing.


Maybe just a wrapper:

zfsassist redundant space-optimized disk0 disk1 disk2
zfsassist redundant speed-optimized disk0 disk1 disk2
zfsassist non-redundant disk0 disk1 disk2

you get the idea.



--
Best regards,
 Robert                            mailto:[EMAIL PROTECTED]
                                       http://milek.blogspot.com


_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to