On Mon, Nov 16, 2009 at 11:41:38PM +1100, Mark Hellewell wrote: > On 16/11/2009, at 3:13 AM, Marco Peereboom wrote: > > > # scsi -f /dev/rsd0c -c "03 00 00 00 fc 00 00" -i 0xfc - | hexdump -C > > 00000000 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |p...............| > > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > > * > > 000000f0 00 00 00 00 00 00 00 00 00 00 00 00 |............| > > 000000fc > > > > byte 0 has to be 0x70 or 0x71 > > byte 7 has to be >= 10 > > But what if it's 0?
then your drive isn't replying correctly. > > > byte 12 is 0x5d if you have a smart trip > > Do you know if that's the same as running a `atactl sd0c smartstatus`? That > simply returns: > > No SMART threshold exceeded look at that! almost useful if it wasn't surrounded by all that other language that is irrelevant. > > on my (hopefully clean) drive - the 12th byte is not 0x5d, at least. > > > this drive is clean! > > > > Figuring out the -i format is left as an exercise for the reader. > > No worries > > > Reading the smartlogs is worthles since you have no idea what bad means > > for that drive. Only the vendors know that. So if byte 12 is set to > > 0x5d toss the damn drive. > > > krw || dlg, you get a cookie if you add this as a boot time command :-) > > > Is it that reliable an indicator that the drive is about to go south? No but that wasn't what you asked. > > Mark
