1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
|
Introduction
============
The win32 port of sg3_utils contains those utilities that are _not_ specific
to Linux. In some cases a utility could be ported but requires more work. An
example is sg_dd which needs more work beyond the SCSI command pass through
mechanism.
Supported Utilities
===================
Here is a list of utilities that have been ported:
sg_format
sg_get_config
sg_ident
sg_inq [dropped ATA IDENTIFY DEVICE capability]
sg_logs
sg_luns
sg_modes
sg_persist
sg_prevent
sg_rdac
sg_read_long
sg_readcap
sg_reassign
sg_requests
sg_rmsn
sg_rtpg
sg_sat_identify
sg_scan [this is Windows specific]
sg_senddiag
sg_ses
sg_start
sg_sync
sg_turs
sg_verify
sg_vpd
sg_wr_mode
sg_write_long
Most utility names are indicative of the main SCSI command that they execute.
Some utilities are slightly higher level, for example sg_ses fetches SCSI
Enclosure Services (SES) status pages and can send control pages. Each
utility has a man page (placed in section 8). There is summary of the mapping
between utility names and the SCSI commands they execute in the COVERAGE
file. An overview of sg3_utils can be found at:
http://www.torque.net/sg/sg3_utils.html .
A copy of the "sg3_utils.html" file is in the "doc" subdirectory.
See the INSTALL file (towards the end) for instructions on how to build
sg3_utils on Windows operating systems. Some man pages have examples which
use linux device names which hopefully will not confuse Windows users.
Details
=======
The ported utilities listed above, all use SCSI command functions declared in
sg_cmds_basic.h and sg_cmds_extra.h . Those SCSI command functions are
implemented in the corresponding ".c" files. The ".c" files pass SCSI commands
to the host operating system via an interface declared in sg_pt.h . There are
currently four implementations of that interface depending on the host
operating system:
- sg_pt_linux.c
- sg_pt_freebsd.c
- sg_pt_osf1.c [Tru64]
- sg_pt_win32.c
The sg_pt_win32.c file uses the Windows SCSI Pass Through (SPT) mechanism.
It does not currently use the ASPI32 interface which requires a dll from
Adaptec. The sg_scan utility is a special version for Windows and it attempts
to show the various allowable device names, grouping various names for the
same device on one line. Here is an example of sg_scan's output:
# sg_scan
SCSI0:0,0,0 C: PD0 IC25N040ATCS05-0 CS4O *
SCSI1:0,0,0 D: CDROM0 HITACHI DVD-ROM GD-S200 0034
SCSI2:0,0,0 I: + PD5 QUANTUM LPS525S 3110
SCSI2:0,6,0 TAPE0 SONY SDT-7000 0192
E: Generic USB SD Reader 1.00 pdt=0
PD1 Generic USB SD Reader 1.00
So the following device names all refer to the same (ATA) disk:
"SCSI0:0,0,0", "C:" and "PD0". Recent version of windows will only allow the
"SCSI0:0,0,0" to be used if there isn't another device name available.
The right hand section of each line is the SCSI INQUIRY command response
strings (which are constructed by Windows is some cases rather than the
device). The "*" at the end of the first line flags that the INQUIRY
response is not quite properly structured (according to SCSI-2) which is
usually indicative of an ATA disk.
If no class driver name (e.g. "PD0", "CDROM0" or "TAPE0") is available
then the SCSI "peripheral device type" (pdt) is placed at the end of the
line. Common pdt values are 0 for disks, 1 for tapes and 5 for cd/dvd
drives. The "+" after the "I:" indicates that other volume names
(letters) map to that device. This occurs when a disk has two or more
partitions that windows recognizes. The longer "PhysicalDrive" name,
shown in Windows documentation, may be used but "PD" is obviously
quicker to type.
Finally sg_scan does not manage to put all device names for USB and
ISS 1394 devices on one line. The last two lines of output are actually
the same device.
Doug Gilbert
16th October 2006
|
