Project

General

Profile

Bug #7901

Updated by Yuri Pankov over 5 years ago

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. 

Back