On Tue, 2 Apr 2002, Evan Harris wrote:
>
> Only one problem, I'm using devfs, so the major/minor means nothing. But
> from looking at online docs, the normal name for the high bit devices is
> nst0, and that just happens to be the device I am using.
>
> But that does explain why the soft error count is always 0 after doing a
> tar, since tar closes the device when it's done, and you stated that it
> loses all history after that. A subsequent call to mt would therefore
> report 0.
>
> I guess the only way to get the info is to hack a call to retrieve the soft
> errors into tar, but I was hoping to avoid that.
>
Quoting from README.st:
The number of recovered errors since the previous status call
is stored in the lower word of the field mt_erreg.
i.e., the number of recovered error is cleared when it is read with
MTIOCGET (e.g., mt status). It does not matter which one of the device
nodes pointing to the same drive you use.
Quoting from 'man st':
mt_erreg The only field defined in mt_erreg is the recovered error count
in the low 16 bits (as defined by MT_ST_SOFTERR_SHIFT and
MT_ST_SOFTERR_MASK). Due to inconsistencies in the way drives
report recovered errors, this count is often not maintained
(most drives do not by default report soft errors but this can
be changed with a SCSI MODE SELECT command).
You should check that your drive is configured to report the soft errors.
This can be done using the mode page 01h (read-write error recovery page,
bit PER). Some drives don't support setting this bit to one. You should be
able to see the value of the bit and change it using the scsi tools
probably included in your distribution.
Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 07 2002 - 22:00:11 EST