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