Autoreplace is currently the biggest advantage that H/W raid controllers have 
over ZFS and other less advanced forms of S/W raid.

I would even go so far as to promote this issue to the forefront as a leading 
deficiency  that is hindering ZFS adoption.

Regarding H/W raid controllers things are kept pretty simply. It does not even 
"try" to discriminate between an admin pulling a good drive (intentional 
removal) and a drive that has failed. While some may see this as less 
sophisticated in reality it makes things quite simple. 

There is a certain degree of decadence and freedom that comes with being able 
to pull a drive out of server A, slap it into server B, and turn on server B 
with a perfect duplicate. Slap a fresh drive from the factory into the now 
vacant slot on server A and rebuild takes place immediatley. 

This has to be the standard. Anything beyond this level of effort simply fails 
against H/W raid. 

There is no standard S/W raid like this and with ZFS's already beautiful 
simplicity, it is the champion of the hour to deliver on this holy grail.

I think this proposal is very close to what we need to take ZFS to the next 
level in the enterprise


Here are some rough thoughts regarding percievable drive failure notification 
(beyond email, pager, console etc)


Literally, someone should be able to make $7/hr with a stack of drives and the 
ability to just look or listen to a server to determin which drive needs to be 
replaced.

This means ZFS will need to be able to control the HDD Status lights on the 
chassis for "look", but for "listen" ZFS could cause the server to beep using 
one beep for the first slot, two beeps in rapid successions, for the second 
slot. A sort of lame Morse code...no device integration on ZFS's part required
 
 
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to