On 2020-02-21 4:46 a.m., Hannes Reinecke wrote:
On 2/20/20 9:08 PM, Douglas Gilbert wrote:
The scsi_debug driver has always been restricted to using one
(or none) ramdisk image for its storage. This means that thousands
of scsi_debug devices can be created without exhausting the host
machine's RAM. The downside is that all scsi_debug devices share
the same ramdisk image. This option doubles the amount of ramdisk
storage space with the first, third, fifth (etc) created
scsi_debug devices using the first ramdisk image while the second,
fourth, sixth (etc) created scsi_debug devices using the second
ramdisk image.
The reason for doing this is to check that (partial) disk to disk
copies based on scsi_debug devices have actually worked properly.
As an example: assume /dev/sdb and /dev/sg1 are the same
scsi_debug device, while /dev/sdc and /dev/sg2 are also the
same scsi_debug device. With doublestore=1 they will have
different ramdisk images. Then the following pseudocode could
be executed to check the if sgh_dd copy worked:
dd if=/dev/urandom of=/dev/sdb
sgh_dd if=/dev/sg1 of=/dev/sg2 [plus option(s) to test]
cmp /dev/sdb /dev/sdc
If the cmp fails then the copy has failed (or some other
mechanism wrote to /dev/sdb or /dev/sdc in the interim).
Signed-off-by: Douglas Gilbert <dgilbert@xxxxxxxxxxxx>
---
drivers/scsi/scsi_debug.c | 264 +++++++++++++++++++++++++++-----------
1 file changed, 186 insertions(+), 78 deletions(-)
Nice use-case, but really should be documented somewhere.
Otherwise:
As stated in the cover letter:
"If and when this patchset is accepted, this page will be
updated: http://sg.danny.cz/sg/sdebug26.html ".
Doing it before then can lead to confusion if the patchset
is not accepted.
One of my scripts for testing the sg driver uses that pattern
with the cmp replaced by:
sgh_dd --verify if=/dev/sg1 of=/dev/sg2
The sg_dd utility also has a --verify option and I plan to add
one the the ddpt utility. The pseudo SCSI command sequence that
it performs is:
PRE-FETCH(sg2, IMMED)
READ(sg1)
VERIFY(sg2, BYTCHK=1, data from READ)
Comparing this pattern to the standard READ-READ approach:
- uses less host CPU and ram resources
- possibly faster in the inequality case
- faster if the host does the READ-READ sequentially
Doug Gilbert
