doug-gilbert / sg3_utils Goto Github PK

Author's own git mirror of his sg3_utils subversion repository. Note: default branch is now _main_. It includes tags from the various releases.

Home Page: https://sg.danny.cz/sg/sg3_utils.html

License: Other

Makefile 0.37% Shell 2.14% C 86.13% M4 0.16% C++ 10.22% Roff 0.07% HTML 0.91%

scsi pass-through command-line storage enclosure

sg3_utils's Introduction

                        README for sg3_utils
                        ====================
Introduction
------------
sg3_utils is a package of utilities originally written to send individual
SCSI commands to storage devices that used one of the SCSI command sets.
These utilities can be divided into three groups:
   - sg_raw: the user supplies the CDB (Command Descriptor Block) and
     optionally the size of the data-in and data-out buffers
   - one command utilities: the majority of the utilities in this package
     send one SCSI command. Their names start with "sg_" while the
     remaining part of their name alludes to the name of the command which
     is sent. For example, "sg_inq" sends the SCSI INQUIRY command. Some
     utilities in this group send one of a selection of commands, typically
     those commands have a lot it common (e.g. sg_write_x).
   - copy type utilities: sg_dd, sgp_dd and sgm_dd use the Unix dd command
     functionality and command line syntax as a template. sg_dd may also be
     used to verify that two storage devices (or part thereof) contain the
     same user data, stopping at the first "miscompare". sg_xcopy sends the
     SCSI EXTENDED COPY command which in some cases can do offloaded copies.

Platforms
---------
These utilities were written on Linux and should work from Linux kernel
(lk) 2.4 through to the current series 6. The third group ("copy type")
are only implemented on Linux, but a separate portable package/utility
called ddpt implements similar functionality. The first two groups are
implemented (i.e. ported) to Android, FreeBSD, NetBSD, Solaris and
Windows.  The Windows port uses either a Cygwin or MinGW (plus Msys)
build environment (rather than Visual Studio).

Library
-------
Many of these utilities share a lot of code (e.g. SCSI error messages)
so a lot of repetition (potentially error prone) is saved by having a
library called libsgutils or some variation on that name. Distributions
(especially of Linux) have differing policies on how a library (and a
package) should be named. For that reason this package is sometimes
known as "sg3-utils" (i.e. the underscore is turned into a hyphen).
Various other packages use libsgutils. The library interface is not
altered from one package release, to the next, but the library interface
may be expanded. If a utility from one release is used with a libsgutils
from an earlier release, then the runtime linking may fail. Typically
package managers take care of these details so that runtime linking
errors should be rare.

Command Sets
------------
SCSI command sets are not the only storage command sets in wide use, there
are also ATA and NVMe command sets. There is a SCSI command set to
translate SCSI commands to ATA commands (called SAT: SCSI to ATA
Translation). SAT includes an ATA PASS-THROUGH SCSI command and sg_sat_*
utilities (there are four) are examples of using SAT. The SAS transport
(Serial Attached SCSI) can convey ATA commands through a SCSI/SAS domain
via its Serial ATA Tunnelled Protocol (STP).

NVMe command sets (e.g. Admin, NVM and MI) are relatively new. There was an
early paper on a SCSI to NVMe Translation Layer (SNTL) but it hasn't been
standardized. The sg_inq utility will send (and decode the response of) a
SCSI INQUIRY command if the underlying device is a SCSI device. If the
underlying device is a NVMe controller or namespace, then sg_inq will send
a NVMe Admin Identify command and decode the response. The sg_ses utility
(for SCSI Enclosure Services) also checks whether its underlying device is
SCSI or NVME. In the NVMe case, sg_ses translates the SCSI SEND DIAGNOSTIC
and READ DIAGNOSTIC RESULTS commands to the NVMe Management Interface (MI)
SES Send and SES Receive commands respectively. The output of the sg_ses
utility should be similar, irrespective of whether the "SES" device is
SCSI or NVMe.

The sg_raw utility may send NVMe Admin or NVM commands (as well as SCSI
commands). One difficulty with a command-line utility invoking NVME
commands is that those commands contain memory addresses for data-in (i.e.
data from the storage device) or data-out (i.e. data sent toward the
storage device) transfers. See the sg_raw manpage for how this difficulty
is addressed.

JSON
----
Taking a lead from smartmontools project, JSON is slowly being added to
those utilities that decode a significant amount of (meta-)data supplied
by storage devices. Human readable output is still the default with the
'--json' option changing the output to JSON. The '--json' option itself
takes an optional argument which is a string where each character turns
on (or off, if preceded by a '-') some attribute of the JSON output
(e.g. '--json=h-e').

One difficulty with JSON (or the json_builder library) is that its integer
representation is signed, 64 bit in size, and rendered in decimal, with a
leading negative sign if needed. However storage metadata tends to use
hexadecimal for large values (e.g. Logical Block Addresses (LBAs)). This
issue is addressed with the 'h' argument (e.g. '--json=h') which changes
decimal rendered numbers into a JSON subobject with two name-value pairs:
one name is 'i' whose value is the same decimal rendered integer, and the
other named 'hex' whose value is a JSON string with that integer rendered
in (unsigned) hexadecimal in that string.

To simplify name decoding in JSON, the "snake notation" convention is used.
This restricts names to the 26 lower case, alphabetical characters (from
English), the 10 digits and underscore. Further an underscore is never the
first or last character of the name and is never repeated. So underscore
can be used as a name separator (e.g. "device_id"). Other JSON producing
utilities follow different naming conventions. One advantage of the "snake
notation" is that it is compatible with various Unix pseudo file system
naming conventions (e.g. procfs and sysfs in Linux).

There is a manual page called "sg3_utils_json" that contains more
information.

Documentation
-------------
Manual pages ("manpages") are the primary method of utility documentation.
All utilities and scripts that are installed by this package have a
manpage. There are utilities in the examples, testing and utils
directories that are not installed and do not have manpages. Nearly
all utilities have runtime help, usually invoked with either the '-h'
short option or the '--help' long option. There is also an overarching
manpage called "sg3_utils". All manpages are placed in chapter 8 which
is for system administration commands/utilities.

The sg3_utils package and some more complex utilities have html pages:
   sg3_utils: https://sg.danny.cz/sg/sg3_utils.html
   sg_ses:    https://sg.danny.cz/sg/sg_ses.html
   sg_dd:     https://sg.danny.cz/sg/sg_dd.html

A tarball (and zip) of all the manpages from the previous release are
here:
   https://sg.danny.cz/sg/p/sg3_utils_man_html.tgz
   https://sg.danny.cz/sg/p/sg3_utils_man_html.zip

There is a html rendering of the sg3_utils manpage in the same directory
as this README file called sg3_utils.man8.html .

The previous README file is now called README.details plus there are
these OS specific files: README.freebsd , README.solaris , README.tru64
and README.win32 . To know the current state of the package the ChangeLog
file is the good reference.

The author's primary source code repository uses subversion and is on
the author's equipment (a RPi). One advantage of subversion is its
revision numbers which are simply integers starting at 1 and ascending.
For this package the current revision is 928 . The subversion repository
is mirrored in git (using "git svn" tools) here:
    https://github.com/doug-gilbert/sg3_utils


Douglas Gilbert
26th April 2023

sg3_utils's People

Stargazers

Watchers

Forkers

tbzatek mwilck bvanassche nitn-yewale cyruran rixon wenchao-hao liuxing108 ratio2 dangyajun figliu1 liubuhe kraj jrbauer-wdc cvubrugier feihe027 jasonbking opensuse patrickdowling

sg3_utils's Issues

Strange behavior of sg_inq -HH option

For some VPD pages, sg_inq -HH behaves oddly:

$ sg_inq -p bdc /dev/sda
VPD INQUIRY: Block device characteristics VPD page (SBC)
  Non-rotating medium (e.g. solid state)
  Product type: Not specified
...
$ sg_inq -H -p bdc /dev/sda
VPD INQUIRY: Block device characteristics VPD page (SBC)
 00     00 b1 00 3c 00 01 00 00  00 00 00 00 00 00 00 00    ...<............
 10     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 20     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 30     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
$ sudo ./src/.libs/sg_inq -HH -p bdc /dev/sda
VPD INQUIRY: Block device characteristics VPD page (SBC)
  Non-rotating medium (e.g. solid state)
  Product type: Not specified
...
$ sg_inq -HHH -p bdc /dev/sda
00 b1 00 3c 00 01 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
$ sg_inq -HHHH -p bdc /dev/sda
00 b1 00 3c 00 01 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

As you can see, -HH decodes the output as if no -H was given at all. This happens for a couple of VPD pages, e.g. lbpv, too. The code looks as if this behavior was intended, but it doesn't make much sense to me.

This seems to be related to the recent JSON work. Bisection shows that (for the bdc VPD page) the behavior changed in the following range of commits afteer r1.47 (inside this range, sg_inq fails because of an unresolved symbol error):

048bd12 sg_inq+sg_vpd: more JSON work (add SG_C_CPP_ZERO_INIT)
4ea97e6 rescan-scsi-bus: sgdevice26: do not traverse sg class if scsi_device isnot added
23beedb sg_inq+sg_vpd: more JSON work (tpc)
640f7a7 cleanup warning and C++20 building issues
aac31a3 (HEAD) rescan-scsi-bus.sh: fix handling of '-I ' option ; sg_inq+sg_vpd: more JSON work

The later commit 7e7308a ("sg_inq+sg_vpd: more updates but not finished") caused sg_inq -H -bdc (only one -H) to falsely print decoded output, too. That was fixed later in 3c4e78e ("C99 cleanup; sg_logs: more tape JSON").

I am uncertain what the inteded behavior of -HH should be, but probably not what's shown above.

Input parameter handling for sg_wr_mode fails...

Hello,

I updated to the latest version of sg3_utils and noticed that some of my test scripts didn't work anymore. After a quick study, I noticed that the sg_wr_mode input parameters are not handled right. Seems that after the latest changes, calling build_mode_page has been moved out from the while clause that's parsing the input parameters. When the build_mode_page is now called, optarg parameter is already NULL. Following changes fixed that for me (-c and -C parameters) but I'm not sure if there's more cases that needs to be updated/fixed.

BR, Affe

@@ -378,8 +378,10 @@ main(int argc, char * argv[])
pr2serr("Cannot have both --contents= and --cfile= options\n");
return SG_LIB_SYNTAX_ERROR;
}

```
          if( cfile_arg )
```

                  contents_arg = cfile_arg;
   memset(read_in, 0, read_in_sz);

   if ((ret = build_mode_page(optarg, !! cfile_arg, do_raw, read_in,

   if ((ret = build_mode_page(contents_arg, !! cfile_arg, do_raw, read_in,
                              &read_in_len, read_in_sz))) {
       pr2serr("bad argument to '%s'\n", cfile_arg ? "--cfile=" :
                                                     "--contents=");

rescan-scsi-bus.sh: when there is a logical lun-0, testonline will spend 30s to retry-check it

In function testonline, this shell uses sg_turs to check sgdevice, but lun-0 is not always a real device, sometimes a logical one. it depends on Vendor's implementation. So could we ensure there is a real sd-device before we check it by sg_turs?

rescan_scsi_bus.sh: Why it's pointless to do a target scan on FC ?

There is comment in rescan_scsi_bus.sh fo FC host which would make it unable to scan single LUN, but what is the reason?
Why do not do target scan on FC?

  if [ -e "/sys/class/fc_host/host$host" ] ; then
    # It's pointless to do a target scan on FC
    issue_lip=/sys/class/fc_host/host$host/issue_lip
    if [ -e "$issue_lip" ] && [ "$lipreset" -ge 0 ] ; then
      echo 1 > "$issue_lip" 2> /dev/null;
      udevadm_settle
      [ "$lipreset" -gt 0 ] && sleep "$lipreset"
    fi
    channelsearch=
    idsearch=

shared library SONAME

Hi,

thanks for maintaining sg3_utils. The build system also builds a libsgutils2-<version>.so.2.0.0, which is used by other software (ledmon, etc).
Given the sg3_utils version number is embedded in the libsgutils2 SONAME, this causes the named other software to break on each sg3_utils version change.

Thus my question:

is libsgutils2 intended to be a "public" library?
is it intended to have a stable ABI?
if so, could the version number be removed from the SONAME again, please?

Thanks,
Chris

rescan-scsi-bus.sh: -r flag unmounts active root disk

Passing the -r flag unmounts the active root disk if it's SCSI

[fedora@localhost ~]$ sudo rescan-scsi-bus.sh -r
Syncing file systems
which: no multipath in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin)
Scanning SCSI subsystem for new devices and remove devices that have disappeared
Scanning host 0 for  SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
 Scanning for device 0 0 2 0 ...           
REM: Host: scsi0 Channel: 00 Id: 02 Lun: 000
      Vendor: IBM      Model: 3303      NVDISK Rev: 0001
      Type:   Direct-Access                    ANSI SCSI revision: 05

Connection to 10.0.0.241 closed by remote host.
Connection to 10.0.0.241 closed.


# system log
[ 6331.532310] EXT4-fs (sda2): shut down requested (2)
[ 6331.532364] Aborting journal on device sda2-8.
[ 6331.532461] device offline error, dev sda, sector 534528 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 2
[ 6331.532705] Buffer I/O error on dev sda2, logical block 65536, lost sync page write
[ 6331.532918] JBD2: I/O error when updating journal superblock for sda2-8.
[ 6331.538722] BTRFS error (device sda5): bdev /dev/sda5 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0
[ 6331.538732] BTRFS error (device sda5): bdev /dev/sda5 errs: wr 2, rd 0, flush 0, corrupt 0, gen 0
[ 6331.538847] BTRFS error (device sda5): bdev /dev/sda5 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0
[ 6331.538922] BTRFS error (device sda5): bdev /dev/sda5 errs: wr 4, rd 0, flush 0, corrupt 0, gen 0

This was partially addressed by #10, but there is another location where certain conditions lead to unintended behaviour. The uses of

sg_turs "$sg_turs_opt" /dev/$SGDEV >/dev/null 2>&1

are incorrect if there are no options, as it passes the empty string as the first argument to sg_turs which treats it as the device positional argument. The quotes should be removed (though I don't know if that affects the case where there is an argument).

Something weird happened in windows... please help me understand.

Until a few days ago I could issue this command:

# sg_raw -r 1k $dev 88 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
# # as well as this command
# sg_raw -r 32k $dev 88 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00

In other words I could read the first kilobyte or the first 32 kilobytes starting from LBA 0.

Since a few days, instead, I can read anything in the range of 512-16384 bytes. Anything more than that and I get:

>>> transport error: The parameter is incorrect.

I am using windows 10.
I don't know if it was some system update or something else but I am sure this happened to someone else.
Can you please help me understand?
SG3_UTILS is one of the few programs that used to work flawlessly both on windows both on linux.

P.S.
I have the same behaviour both in CYGWIN both in MSYS.
It must be something in the system but I don't know what.
I uninstalled all usb filters or anything related.

Note: this happens with ANY command... not only reading a sector.
It's like the receive buffer is capped at 32k.

Obviously, in linux the same commands work with receive buffer >32K as usual.

rescan-scsi-bus.sh: function "findremapped" is too slow when there is 1K luns on server，is there any way to solve it?

There is a loop nesting in function "findremapped".
we use "scsi-rescan -f -u -m" to scan all devices.

while read -r hctl sddev id_serial_old ; do
    remapped=0
    ……
    # If udev events updated the disks already, but the multipath device isn't update
    # check for old devices to make sure we found remapped luns
    if [ -n "$mp_enable" ] && [ $remapped -eq 0 ]; then
      findmultipath "$sddev" $id_serial    
      if [ $? -eq 1 ] ; then
        remapped=1
      fi
    fi
    ……
done < $tmpfile

The sorting order of the output numeric part is out of order

Scanning SCSI subsystem for new devices
Scanning host 0 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning for device 0 0 0 0 ...
OLD: Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: VMware Model: Virtual disk Rev: 2.0
Type: Direct-Access ANSI SCSI revision: 06
Scanning host 1 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 10 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 11 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 12 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 13 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 14 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 15 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 16 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 17 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 18 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 19 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 2 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 20 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 21 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 22 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 23 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 24 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 25 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 26 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 27 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 28 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 29 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 3 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 30 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 31 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 32 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 4 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 6 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 7 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 8 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 9 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
0 new or changed device(s) found.
0 remapped or resized device(s) found.
0 device(s) removed.

v1.42 is normal

Scanning SCSI subsystem for new devices
Scanning host 0 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning for device 0 0 0 0 ...
OLD: Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: VMware Model: Virtual disk Rev: 2.0
Type: Direct-Access ANSI SCSI revision: 06
Scanning host 1 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 2 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 3 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 4 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning for device 4 0 0 0 ...
OLD: Host: scsi4 Channel: 00 Id: 00 Lun: 00
Vendor: NECVMWar Model: VMware SATA CD01 Rev: 1.00
Type: CD-ROM ANSI SCSI revision: 05
Scanning host 5 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 6 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 7 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 8 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 9 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 10 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 11 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 12 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 13 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 14 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 15 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 16 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 17 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 18 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 19 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 20 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 21 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 22 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 23 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 24 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 25 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 26 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 27 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 28 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 29 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 30 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 31 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 32 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
0 new or changed device(s) found.
0 remapped or resized device(s) found.
0 device(s) removed.

invalid VPD response; probably a STANDARD INQUIRY response

# /usr/local/sbin/rescan-scsi-bus.sh -V
20220930

# rpm -q sg3_utils
sg3_utils-1.46-5.fc38.x86_64

# /usr/local/sbin/rescan-scsi-bus.sh 
Scanning SCSI subsystem for new devices
Scanning host 0 for  SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
 Scanning for device 0 0 0 0 ... 
OLD:  Host: scsi0 Channel: 00 Id: 00 Lun: 00
      Vendor: ATA      Model: OCZ-AGILITY3     Rev: 2.50
      Type:   Direct-Access                    ANSI SCSI revision: 05
Scanning host 1 for  SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 2 for  SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 3 for  SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 4 for  SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 5 for  SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
egrep: warning: egrep is obsolescent; using grep -E
 Scanning for device 5 0 0 0 ...           
OLD:  Host: scsi5 Channel: 00 Id: 00 Lun: 00
      Vendor: hp       Model: DVD-RAM GH80N    Rev: RF03
      Type:   CD-ROM                           ANSI SCSI revision: 05
..............................Scanning host 6 for  SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
 Scanning for device 6 0 0 0 ... 
OLD:  Host: scsi6 Channel: 00 Id: 00 Lun: 00
      Vendor: ATA      Model: Samsung SSD 860  Rev: 4B6Q
      Type:   Direct-Access                    ANSI SCSI revision: 05
Scanning host 7 for  SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
 Scanning for device 7 0 0 0 ... 
OLD:  Host: scsi7 Channel: 00 Id: 00 Lun: 00
      Vendor: ATA      Model: WDC WD40EZRZ-00G Rev: 0A80
      Type:   Direct-Access                    ANSI SCSI revision: 05
Scanning host 8 for  SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
 Scanning for device 8 0 0 0 ... 
OLD:  Host: scsi8 Channel: 00 Id: 00 Lun: 00
      Vendor: WD       Model: My Book 25EE     Rev: 4009
      Type:   Direct-Access                    ANSI SCSI revision: 06
 Scanning for device 8 0 0 1 ... 
OLD:  Host: scsi8 Channel: 00 Id: 00 Lun: 01
      Vendor: WD       Model: SES Device       Rev: 4009
      Type:   Enclosure                        ANSI SCSI revision: 06
Scanning host 9 for  SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
egrep: warning: egrep is obsolescent; using grep -E
 Scanning for device 9 0 0 0 ...           
OLD:  Host: scsi9 Channel: 00 Id: 00 Lun: 00
      Vendor: Multiple Model: Card  Reader     Rev: 1.00
      Type:   Direct-Access                    ANSI SCSI revision: -1
invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.invalid VPD response; probably a STANDARD INQUIRY response
.Scanning host 10 for  SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
 Scanning for device 10 0 0 0 ... 
OLD:  Host: scsi10 Channel: 00 Id: 00 Lun: 00
      Vendor: WD       Model: My Passport 070A Rev: 2018
      Type:   Direct-Access                    ANSI SCSI revision: 04
 Scanning for device 10 0 0 1 ... 092005375 ... 
OLD:  Host: scsi10 Channel: 00 Id: 00 Lun: 01
      Vendor: WD       Model: SES Device       Rev: 2018
      Type:   Enclosure                        ANSI SCSI revision: 04
0 new or changed device(s) found.          
0 remapped or resized device(s) found.
0 device(s) removed.

is it a bug? or a normal response?

Thank you.

Regression in sgp_dd command

Hi @doug-gilbert,

There seems to be a regression in sgp_dd command. Please see the following log.

root@phdev:~/sg3_utils # sgp_dd if=/dev/null of=sg3 bs=512 count=1
>>>> Some error occurred, remaining blocks=-3
  remaining block count=1
0+0 records in
0+0 records out

This is in version 1.47 and there in the current HEAD as well. Please let me know if I'm using the tool wrong. Thanks.

Identify device output for SATA on big endian

When I run sg_inq -p 0x89 /dev/sdf for a SSD I have in a little endian system, I get the following (SN redacted):

# sg_inq -p 0x89 /dev/sdf
VPD INQUIRY: ATA information page
  SAT Vendor identification: linux   
  SAT Product identification: libata          
  SAT Product revision level: 3.00
  Signature (Device to host FIS):
 00     34 80 40 00 01 00 00 00  00 00 00 00 01 00 00 00
 10     00 00 00 00
  ATA command IDENTIFY DEVICE response summary:
    model: Samsung SSD 850 EVO 1TB                 
    serial number:     
    firmware revision: EMT01B6Q
  response in hex:
 00     0040 3fff c837 0010 0000 0000 003f 0000     .@ ?. .7 .. .. .. .? .. 
 08     0000 0000 2020 2020 2020 2020 2020 2020     .. .. 
 10     2020 2020 2020 2020 0000 0000 0000 454d                 .. .. .. EM 
 18     5430 3142 3651 5361 6d73 756e 6720 5353     T0 1B 6Q Sa ms un g  SS 
 20     4420 3835 3020 4556 4f20 3154 4220 2020     D  85 0  EV O  1T B     
 28     2020 2020 2020 2020 2020 2020 2020 8001                          .. 
 30     4001 2f00 4000 0200 0200 0007 3fff 0010     @. /. @. .. .. .. ?. .. 
 38     003f fc10 00fb 0101 ffff 0fff 0000 0007     .? .. .. .. .. .. .. .. 
 40     0003 0078 0078 0078 0078 0f10 0000 0000     .. .x .x .x .x .. .. .. 
 48     0000 0000 0000 001f 850e 00c4 016c 0060     .. .. .. .. .. .. .l .` 
 50     03fc 0039 746b 7d01 4163 7469 bc01 4163     .. .9 tk }. Ac ti .. Ac 
 58     407f 0001 0004 0000 fffe 0000 0000 0000     @. .. .. .. .. .. .. .. 
 60     0000 0000 0000 0000 6db0 7470 0000 0000     .. .. .. .. m. tp .. .. 
 68     0000 0008 4000 0000 5002 5388 700a daad     .. .. @. .. P. S. p. .. 
 70     0000 0000 0000 0000 0000 0000 0000 401e     .. .. .. .. .. .. .. @. 
 78     401c 0000 0000 0000 0000 0000 0000 0000     @. .. .. .. .. .. .. .. 
 80     0021 0000 0000 0000 0000 0000 0000 0000     .! .. .. .. .. .. .. .. 
 88     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 90     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 98     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 a0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 a8     0000 0001 2020 2020 2020 2020 0000 0000     .. ..             .. .. 
 b0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 b8     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 c0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 c8     0000 0000 0000 0000 0000 0000 003d 0000     .. .. .. .. .. .. .= .. 
 d0     0000 4000 0000 0000 0000 0000 0000 0000     .. @. .. .. .. .. .. .. 
 d8     0000 0001 0000 0000 0000 0000 107f 0000     .. .. .. .. .. .. .. .. 
 e0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 e8     0000 0000 0000 0800 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 f0     0000 0000 0000 4000 0000 0000 0000 0000     .. .. .. @. .. .. .. .. 
 f8     0000 0000 0000 0000 0000 0000 0000 87a5     .. .. .. .. .. .. .. ..

Same device in a big endian system:

# ./sg_inq --page 0x89 /dev/sdb
VPD INQUIRY: ATA information page
  SAT Vendor identification: linux   
  SAT Product identification: libata          
  SAT Product revision level: 3.00
  Signature (Device to host FIS):
 00     34 80 40 00 01 00 00 00  00 00 00 00 01 00 00 00
 10     00 00 00 00
  ATA command IDENTIFY DEVICE response summary:
    model: aSsmnu gSS D58 0VE OT1 B                
    serial number:     
    firmware revision: ME0TB1Q6
  response in hex:
 00     4000 ff3f 37c8 1000 0000 0000 3f00 0000     @. .? 7. .. .. .. ?. .. 
 08     0000 0000 2020 2020 2020 2020 2020 2020     .. .. 
 10     2020 2020 2020 2020 0000 0000 0000 4d45                 .. .. .. ME 
 18     3054 4231 5136 6153 736d 6e75 2067 5353     0T B1 Q6 aS sm nu  g SS 
 20     2044 3538 2030 5645 204f 5431 2042 2020      D 58  0 VE  O T1  B    
 28     2020 2020 2020 2020 2020 2020 2020 0180                          .. 
 30     0140 002f 0040 0002 0002 0700 ff3f 1000     .@ ./ .@ .. .. .. .? .. 
 38     3f00 10fc fb00 0101 ffff ff0f 0000 0700     ?. .. .. .. .. .. .. .. 
 40     0300 7800 7800 7800 7800 100f 0000 0000     .. x. x. x. x. .. .. .. 
 48     0000 0000 0000 1f00 0e85 c200 6c01 6000     .. .. .. .. .. .. l. `. 
 50     fc03 3900 6b74 017d 6341 6974 01bc 6341     .. 9. kt .} cA it .. cA 
 58     7f40 0100 0400 0000 feff 0000 0000 0000     .@ .. .. .. .. .. .. .. 
 60     0000 0000 0000 0000 b06d 7074 0000 0000     .. .. .. .. .m pt .. .. 
 68     0000 0800 0040 0000 0250 8853 0a70 adda     .. .. .@ .. .P .S .p .. 
 70     0000 0000 0000 0000 0000 0000 0000 1e40     .. .. .. .. .. .. .. .@ 
 78     1c40 0000 0000 0000 0000 0000 0000 0000     .@ .. .. .. .. .. .. .. 
 80     2100 0000 0000 0000 0000 0000 0000 0000     !. .. .. .. .. .. .. .. 
 88     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 90     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 98     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 a0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 a8     0000 0100 2020 2020 2020 2020 0000 0000     .. ..             .. .. 
 b0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 b8     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 c0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 c8     0000 0000 0000 0000 0000 0000 3d00 0000     .. .. .. .. .. .. =. .. 
 d0     0000 0040 0000 0000 0000 0000 0000 0000     .. .@ .. .. .. .. .. .. 
 d8     0000 0100 0000 0000 0000 0000 7f10 0000     .. .. .. .. .. .. .. .. 
 e0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 e8     0000 0000 0000 0008 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 f0     0000 0000 0000 0040 0000 0000 0000 0000     .. .. .. .@ .. .. .. .. 
 f8     0000 0000 0000 0000 0000 0000 0000 a589     .. .. .. .. .. .. .. ..

From looking at the ATA specification,

Unless stated or defined otherwise, in a field containing a multi-byte value (e.g., a word, DWord, or QWord),
the byte containing the LSB is stored at the lowest offset and the byte containing the MSB is stored at the
highest offset.

seems to fit the description as "little endian". Looking at the output, things look correct from a strings stand point on LE system for model etc., but the hex dump for "little endian" system output looks like "big endian" output, in that the LSB is in the higher address/byte location.

If I do the following on a LE hardware, I'm assuming it's dumping the bytes in the order from the request:

# sg_inq -H -p 0x89 /dev/sdf
VPD INQUIRY, page code=0x89:
 00     00 89 02 38 00 00 00 00  6c 69 6e 75 78 20 20 20    ...8....linux   
 10     6c 69 62 61 74 61 20 20  20 20 20 20 20 20 20 20    libata          
 20     33 2e 30 30 34 80 40 00  01 00 00 00 00 00 00 00    3.004.@.........
 30     01 00 00 00 00 00 00 00  ec 00 00 00 40 00 ff 3f    ............@..?
 40     37 c8 10 00 00 00 00 00  3f 00 00 00 00 00 00 00    7.......?.......
 50     20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
 60     20 20 20 20 00 00 00 00  00 00 4d 45 30 54 42 31        ......ME0TB1
 70     51 36 61 53 73 6d 6e 75  20 67 53 53 20 44 35 38    Q6aSsmnu gSS D58
 80     20 30 56 45 20 4f 54 31  20 42 20 20 20 20 20 20     0VE OT1 B      
 90     20 20 20 20 20 20 20 20  20 20 01 80 01 40 00 2f              ...@./
 a0     00 40 00 02 00 02 07 00  ff 3f 10 00 3f 00 10 fc    .@.......?..?...
 b0     fb 00 01 01 ff ff ff 0f  00 00 07 00 03 00 78 00    ..............x.
 c0     78 00 78 00 78 00 10 0f  00 00 00 00 00 00 00 00    x.x.x...........
 d0     00 00 1f 00 0e 85 c4 00  6c 01 60 00 fc 03 39 00    ........l.`...9.
 e0     6b 74 01 7d 63 41 69 74  01 bc 63 41 7f 40 01 00    kt.}cAit..cA.@..
 f0     04 00 00 00 fe ff 00 00  00 00 00 00 00 00 00 00    ................
 100    00 00 00 00 b0 6d 70 74  00 00 00 00 00 00 08 00    .....mpt........
 110    00 40 00 00 02 50 88 53  0a 70 ad da 00 00 00 00    [email protected]......
 120    00 00 00 00 00 00 00 00  00 00 1e 40 1c 40 00 00    ...........@.@..
 130    00 00 00 00 00 00 00 00  00 00 00 00 21 00 00 00    ............!...
 140    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 150    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 160    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 170    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 180    00 00 00 00 00 00 00 00  00 00 00 00 00 00 01 00    ................
 190    20 20 20 20 20 20 20 20  00 00 00 00 00 00 00 00            ........
 1a0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 1b0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 1c0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 1d0    00 00 00 00 00 00 00 00  3d 00 00 00 00 00 00 40    ........=......@
 1e0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 01 00    ................
 1f0    00 00 00 00 00 00 00 00  7f 10 00 00 00 00 00 00    ................
 200    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 210    00 00 00 08 00 00 00 00  00 00 00 00 00 00 00 00    ................
 220    00 00 00 40 00 00 00 00  00 00 00 00 00 00 00 00    ...@............
 230    00 00 00 00 00 00 00 00  00 00 a5 87                ............

I'm not sure at this point what the correct answer is.

sg_logs: output for Device Statistics page (14h), serial numbers should be strings?

Hi,
stumbled across this output for sg_logs --page=0x14 on a tape device:

Device statistics page (ssc-3 and adc)
  Lifetime media loads: 0
  Drive manufacturer's serial number: 0
  Drive serial number: 0

Should parameter codes 0x40 and 0x41 be printed as string data?
https://github.com/doug-gilbert/sg3_utils/blob/main/src/sg_logs.c#L8038

Thanks!