Commit Graph

15 Commits

Author SHA1 Message Date
ken
b09a0cbe0a Improve camcontrol(8) handling of drive defect data.
This includes a new summary mode (-s) for camcontrol defects that
quickly tells the user the most important thing: how many defects
are in the requested list.  The actual location of the defects is
less important.

Modern drives frequently have more than the 8191 defects that can
be reported by the READ DEFECT DATA (10) command.  If they don't
have that many grown defects, they certainly have more than 8191
defects in the primary (i.e. factory) defect list.

The READ DEFECT DATA (12) command allows for longer parameter
lists, as well as indexing into the list of defects, and so allows
reporting many more defects.

This has been tested with HGST drives and Seagate drives, but
does not fully work with Seagate drives.  Once I have a Seagate
spec I may be able to determine whether it is possible to make it
work with Seagate drives.

scsi_da.h:	Add a definition for the new long block defect
		format.

		Add bit and mask definitions for the new extended
		physical sector and bytes from index defect
		formats.

		Add a prototype for the new scsi_read_defects() CDB
		building function.

scsi_da.c:	Add a new scsi_read_defects() CDB building function.
		camcontrol(8) was previously composing CDBs manually.
		This is long overdue.

camcontrol.c:	Revamp the camcontrol defects subcommand.  We now
		go through multiple stages in trying to get defect
		data off the drive while avoiding various drive
		firmware quirks.

		We start off by requesting the defect header with
		the 10 byte command.  If we're in summary mode (-s)
		and the drive reports fewer defects than can be
		represented in the 10 byte header, we're done.
		Otherwise, we know that we need to issue the
		12 byte command if the drive reports the maximum
		number of defects.

		If we're in summary mode, we're done if we get a
		good response back when asking for the 12 byte header.

		If the user has asked for the full list, then we
		use the address descriptor index field in the 12
		byte CDB to step through the list in 64K chunks.
		64K is small enough to work with most any ancient
		or modern SCSI controller.

		Add support for printing the new long block defect
		format, as well as the extended physical sector and
		bytes from index formats.  I don't have any drives
		that support the new formats.

		Add a hexadecimal output format that can be turned
		on with -X.

		Add a quiet mode (-q) that can be turned on with
		the summary mode (-s) to just print out a number.

		Revamp the error detection and recovery code for
		the defects command to work with HGST drives.

		Call the new scsi_read_defects() CDB building
		function instead of rolling the CDB ourselves.

		Pay attention to the residual from the defect list
		request when printing it out, so we don't run off
		the end of the list.

		Use the new scsi_nv library routines to convert
		from strings to numbers and back.

camcontrol.8:	Document the new defect formats (longblock, extbfi,
		extphys) and command line options (-q, -s, -S and
		-X) for the defects subcommand.

		Explain a little more about what drives generally
		do and don't support.

Sponsored by:	Spectra Logic
MFC after:	1 week
2015-01-08 16:58:40 +00:00
mav
871e8858c4 Add LBPERE mode bit definition. 2014-10-14 08:30:02 +00:00
mav
6a41a7221d Add support for READ DEFECT DATA (10/12) commands.
SPC-4 r2 allows to return empty defect list if the list is not supported.
We don't reallu support defect data lists, but this suppresses some errors.

MFC after:	1 week
2014-10-13 14:48:49 +00:00
mav
6f0acfd6e3 Add support for VERIFY(10/12/16) and COMPARE AND WRITE SCSI commands.
Make data_submit backends method support not only read and write requests,
but also two new ones: verify and compare.  Verify just checks readability
of the data in specified location without transferring them outside.
Compare reads the specified data and compares them to received data,
returning error if they are different.

VERIFY(10/12/16) commands request either verify or compare from backend,
depending on BYTCHK CDB field.  COMPARE AND WRITE command executed in two
stages: first it requests compare, and then, if succeesed, requests write.
Atomicity of operation is guarantied by CTL request ordering code.

MFC after:	2 weeks
Sponsored by:	iXsystems, Inc.
2014-06-16 11:00:14 +00:00
bryanv
4dc4ea3c0d Add camcontrol support for the SCSI sanitize command
Reviewed by:	ken, mjacob (eariler version)
Sponsored by:	Netapp
2013-09-06 15:19:57 +00:00
ken
e2f0baed00 Change 'camcontrol defects' to first probe a drive to find out how much
defect information it has before grabbing the full defect list.

This works around a bug with some Hitachi drives that generate data overrun
errors when they are asked for more defect data than they have.

The change is done in a spec-compliant way, so it should have no negative
impact on drives that don't have this issue.

This is based on work originally done at Sandvine.

scsi_da.h:	Add a define for the maximum amount of data that can be
		contained in a defect list.

camcontrol.c:	Update the readdefects() function to issue an initial
		command to determine the length of the defect list, and
		then use that length in the request for the full defect
		list.

camcontrol.8:	Add a note that some drives will report 0 defects available
		if you don't request either the PLIST or GLIST.

Submitted by:	Mark Johnston <markjdb@gmail.com> (original version)
MFC after:	3 days
2012-06-22 18:57:06 +00:00
ken
fce645c153 Add the CAM Target Layer (CTL).
CTL is a disk and processor device emulation subsystem originally written
for Copan Systems under Linux starting in 2003.  It has been shipping in
Copan (now SGI) products since 2005.

It was ported to FreeBSD in 2008, and thanks to an agreement between SGI
(who acquired Copan's assets in 2010) and Spectra Logic in 2010, CTL is
available under a BSD-style license.  The intent behind the agreement was
that Spectra would work to get CTL into the FreeBSD tree.

Some CTL features:

 - Disk and processor device emulation.
 - Tagged queueing
 - SCSI task attribute support (ordered, head of queue, simple tags)
 - SCSI implicit command ordering support.  (e.g. if a read follows a mode
   select, the read will be blocked until the mode select completes.)
 - Full task management support (abort, LUN reset, target reset, etc.)
 - Support for multiple ports
 - Support for multiple simultaneous initiators
 - Support for multiple simultaneous backing stores
 - Persistent reservation support
 - Mode sense/select support
 - Error injection support
 - High Availability support (1)
 - All I/O handled in-kernel, no userland context switch overhead.

(1) HA Support is just an API stub, and needs much more to be fully
    functional.

ctl.c:			The core of CTL.  Command handlers and processing,
			character driver, and HA support are here.

ctl.h:			Basic function declarations and data structures.

ctl_backend.c,
ctl_backend.h:		The basic CTL backend API.

ctl_backend_block.c,
ctl_backend_block.h:	The block and file backend.  This allows for using
			a disk or a file as the backing store for a LUN.
			Multiple threads are started to do I/O to the
			backing device, primarily because the VFS API
			requires that to get any concurrency.

ctl_backend_ramdisk.c:	A "fake" ramdisk backend.  It only allocates a
			small amount of memory to act as a source and sink
			for reads and writes from an initiator.  Therefore
			it cannot be used for any real data, but it can be
			used to test for throughput.  It can also be used
			to test initiators' support for extremely large LUNs.

ctl_cmd_table.c:	This is a table with all 256 possible SCSI opcodes,
			and command handler functions defined for supported
			opcodes.

ctl_debug.h:		Debugging support.

ctl_error.c,
ctl_error.h:		CTL-specific wrappers around the CAM sense building
			functions.

ctl_frontend.c,
ctl_frontend.h:		These files define the basic CTL frontend port API.

ctl_frontend_cam_sim.c:	This is a CTL frontend port that is also a CAM SIM.
			This frontend allows for using CTL without any
			target-capable hardware.  So any LUNs you create in
			CTL are visible in CAM via this port.

ctl_frontend_internal.c,
ctl_frontend_internal.h:
			This is a frontend port written for Copan to do
			some system-specific tasks that required sending
			commands into CTL from inside the kernel.  This
			isn't entirely relevant to FreeBSD in general,
			but can perhaps be repurposed.

ctl_ha.h:		This is a stubbed-out High Availability API.  Much
			more is needed for full HA support.  See the
			comments in the header and the description of what
			is needed in the README.ctl.txt file for more
			details.

ctl_io.h:		This defines most of the core CTL I/O structures.
			union ctl_io is conceptually very similar to CAM's
			union ccb.

ctl_ioctl.h:		This defines all ioctls available through the CTL
			character device, and the data structures needed
			for those ioctls.

ctl_mem_pool.c,
ctl_mem_pool.h:		Generic memory pool implementation used by the
			internal frontend.

ctl_private.h:		Private data structres (e.g. CTL softc) and
			function prototypes.  This also includes the SCSI
			vendor and product names used by CTL.

ctl_scsi_all.c,
ctl_scsi_all.h:		CTL wrappers around CAM sense printing functions.

ctl_ser_table.c:	Command serialization table.  This defines what
			happens when one type of command is followed by
			another type of command.

ctl_util.c,
ctl_util.h:		CTL utility functions, primarily designed to be
			used from userland.  See ctladm for the primary
			consumer of these functions.  These include CDB
			building functions.

scsi_ctl.c:		CAM target peripheral driver and CTL frontend port.
			This is the path into CTL for commands from
			target-capable hardware/SIMs.

README.ctl.txt:		CTL code features, roadmap, to-do list.

usr.sbin/Makefile:	Add ctladm.

ctladm/Makefile,
ctladm/ctladm.8,
ctladm/ctladm.c,
ctladm/ctladm.h,
ctladm/util.c:		ctladm(8) is the CTL management utility.
			It fills a role similar to camcontrol(8).
			It allow configuring LUNs, issuing commands,
			injecting errors and various other control
			functions.

usr.bin/Makefile:	Add ctlstat.

ctlstat/Makefile
ctlstat/ctlstat.8,
ctlstat/ctlstat.c:	ctlstat(8) fills a role similar to iostat(8).
			It reports I/O statistics for CTL.

sys/conf/files:		Add CTL files.

sys/conf/NOTES:		Add device ctl.

sys/cam/scsi_all.h:	To conform to more recent specs, the inquiry CDB
			length field is now 2 bytes long.

			Add several mode page definitions for CTL.

sys/cam/scsi_all.c:	Handle the new 2 byte inquiry length.

sys/dev/ciss/ciss.c,
sys/dev/ata/atapi-cam.c,
sys/cam/scsi/scsi_targ_bh.c,
scsi_target/scsi_cmds.c,
mlxcontrol/interface.c:	Update for 2 byte inquiry length field.

scsi_da.h:		Add versions of the format and rigid disk pages
			that are in a more reasonable format for CTL.

amd64/conf/GENERIC,
i386/conf/GENERIC,
ia64/conf/GENERIC,
sparc64/conf/GENERIC:	Add device ctl.

i386/conf/PAE:		The CTL frontend SIM at least does not compile
			cleanly on PAE.

Sponsored by:	Copan Systems, SGI and Spectra Logic
MFC after:	1 month
2012-01-12 00:34:33 +00:00
imp
362fcfc1e2 Start each of the license/copyright comments with /*- 2005-01-05 22:34:37 +00:00
bms
2d923cd7cb Remove references to the second byte of a CCB containing the LUN, as this
is valid only for SCSI-2 and older devices.
Rename the second byte of the VERIFY CCB from 'lun' to 'byte2'.

Submitted by:	ken
MFC after:	2 weeks
2004-10-13 09:31:04 +00:00
bms
29ae8584ac Add necessary data structures and definitions for the 12-byte SCSI
commands READ_FORMAT_CAPACITIES, WRITE_AND_VERIFY, and VERIFY.

Reviewed by:	ken, scottl
Source:		USB Mass Storage UFI Specification v1.0
MFC after:	2 weeks
2004-10-12 08:55:02 +00:00
ken
d6e8bd4cd5 Implement a new camcontrol function, 'camcontrol format'.
libcam/Makefile:	Add scsi_da.c to libcam for the new
			scsi_format_unit() function.

camcontrol.8:		Update the man page for the new format
			functionality, and take out the examples section
			describing how to do it with 'camcontrol cmd'.

camcontrol.c:		New format functionality.  Note that unlike the
			rest of the camcontrol subcommands, this one is
			interactive by default.  Because of the potential
			destructiveness of the format command, I thought
			it necessary to get confirmation from the user
			before spamming a disk.  You can disable the
			interactive behavior, and the status meter with
			command line arguments.

scsi_da.c:		Add the new scsi_format_unit() cdb building
			function and use #ifdef _KERNEL to make this file
			compile in both the kernel and userland.  The
			format unit function is currently only defined in
			the non-kernel case, because nothing in the kernel
			is using it.  If that changes, it should be
			un-ifdefed and compiled in both cases.

scsi_da.h:		New function declaration, CDB structure and format
			data structures.

Thanks to Nick Hibma for providing some valuable input on these changes.
2000-05-21 23:57:52 +00:00
n_hibma
c79db87671 Various typo's.
One minor nit. The speed was displayed wrong when below 1Mb/s.
2000-03-15 21:55:48 +00:00
peter
3b842d34e8 $Id$ -> $FreeBSD$ 1999-08-28 01:08:13 +00:00
ken
b1e2d556fc Fix the CAM code so that people can compile kernels with the CD driver but
without the DA driver.

The problem was that the CD driver depended on scsi_read_write() and
scsi_start_stop(), which were defined in scsi_da.c.

I moved both functions, and their associated data structures and defines
from scsi_da.* to scsi_all.*.  This is technically the "wrong" thing to do
since those commands are really only for direct-access type devices, not
for all SCSI devices.  I think, though, that the advantage (allowing people
to compile kernels without the disk driver) outweighs any architectural
purity arguments.

PR:		kern/7969
Reviewed by:	gibbs
1998-09-18 22:33:59 +00:00
gibbs
cb986cde46 SCSI Peripheral drivers for CAM:
da	- Direct Access Devices (disks, optical devices, SS disks)
	cd	- CDROM (or devices that can act like them, WORM, CD-RW, etc)
	ch	- Medium Changer devices.
	sa	- Sequential Access Devices (tape drives)
	pass	- Application pass-thru driver
	targ	- Target Mode "Processor Target" Emulator
	pt	- Processor Target Devices (scanners, cpus, etc.)

Submitted by:	The CAM Team
1998-09-15 06:36:34 +00:00