The soon to be released smartmontools 5.34 uses the
READ DEFECT DATA command on SCSI disks. A disk that
has defect list entries (or worse, an increasing number
of them) is at risk.
Currently the first invocation of smartctl causes this:
scsi: unknown opcode 0x37
message to appear the console and in the log.
The READ DEFECT DATA SCSI command does not change
the state of a disk. Its opcode (0x37) is valid for
SBC devices (e.g. disks) and SMC-2 devices (media
changers) where it is called INITIALIZE STATUS ELEMENT
WITH RANGE and again doesn't change the external state
of the device.
Changelog:
- mark SCSI opcode 0x37 (READ DEFECT DATA) as
safe_for_read
Signed-off-by: Douglas Gilbert <dougg@torque.net>
Acked-by: Jens Axboe <axboe@suse.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Original From: Mike Christie <michaelc@cs.wisc.edu>
Modified to split out block changes (this patch) and SCSI pieces.
Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Change the blk_rq_map_user() and blk_rq_map_kern() interface to require
a previously allocated request to be passed in. This is both more efficient
for multiple iterations of mapping data to the same request, and it is also
a much nicer API.
Signed-off-by: Jens Axboe <axboe@suse.de>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
