Description by Jeffry Molanus. There is a very long outstanding issue around zeus rams and perhaps others, where the system tries to enable the Write Cache (WC). This generates an ereport on each vdev_disk_open() and the ereport DB can grow substantially over time with lots of reports indicating the problem. This makes figuring out whats wrong, if anything, needlessly hard/difficult for the support engineer but also with things like collector/autosupport and the new UI. Also, the ereports trigger other parts of the system to kick in gear in particular FMD and we could really spare the IOPs and CPU cycles if we become a little smarter when handling the DKIOCSETWCE ioctl. Using dtrace is easy to find out what disk and operation is causing the error <pre> CPU ID FUNCTION:NAME 4 32548 scsi_transport:entry sd`sd_start_cmds+0x25f sd`sd_core_iostart+0xf7 sd`sd_uscsi_strategy+0x15f genunix`default_physio+0x33d genunix`physio+0x25 scsi`scsi_uscsi_handle_cmd+0x2a5 sd`sd_ssc_send+0x195 sd`sd_send_scsi_MODE_SELECT+0x1ca sd`sd_cache_control+0x3d4 sd`sdioctl+0x1bfb genunix`cdev_ioctl+0x39 genunix`ldi_ioctl+0x88 zfs`vdev_disk_open+0x297 zfs`vdev_open+0x1d5 zfs`vdev_open_child+0x28 genunix`taskq_thread+0x318 unix`thread_start+0x8 </pre> When we issue the @MODE SENSE(10)@ MODE SENSE(10) we should prior to that set the page control field to 1, and verify the setting is changeable before we just blindly modify the bit. the STEC zeusram does not support changing this bit and as result we generate sense data which triggers the ereport over and over and over again as we dont learn from our failures.