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