Skip to content

L
linux
Switch branch/tag
  1. 05 May, 2020 6 commits
    • Douglas Gilbert's avatar
      scsi: scsi_debug: Implement PRE-FETCH commands · ed9f3e25
      Douglas Gilbert authored 
      Many disks implement the SCSI PRE-FETCH commands. One use case might be a
disk-to-disk compare, say between disks A and B. Then this sequence of
commands might be used: PRE-FETCH(from B, IMMED), READ(from A), VERIFY
(BYTCHK=1 on B with data returned from READ).  The PRE-FETCH (which returns
quickly due to the IMMED) fetches the data from the media into B's cache
which should speed the trailing VERIFY command. The next chunk of the
compare might be done in parallel, with A and B reversed.

The implementation tries to bring the specified range in main memory into
the cache(s) associated with this machine's CPU(s) using the
prefetch_range() function.

Link: https://lore.kernel.org/r/20200421151424.32668-7-dgilbert@interlog.comSigned-off-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      ed9f3e25
    • Douglas Gilbert's avatar
      scsi: scsi_debug: Improve command duration calculation · a2aede97
      Douglas Gilbert authored 
      Previously the code did the work implied by the given SCSI command and
after that it waited for a timer based on the user specified command
duration to be exhausted before informing the mid-level that the command
was complete. For short command durations, the time to complete the work
implied by the SCSI command could be significant compared to the user
specified command duration.

For example a WRITE of 128 blocks (say 512 bytes each) on a machine that
can copy from main memory to main memory at a rate of 10 GB/sec will take
around 6.4 microseconds to do that copy.  If the user specified a command
duration of 5 microseconds (ndelay=5000), should the driver do a further
delay of 5 microseconds after the copy or return immediately because 6.4 >
5 ?

The action prior to this patch was to always do the timer based
delay. After this patch, for ndelay values less than 1 millisecond, this
driver will complete the command immediately.  And in the case where the
user specified delay was 7 microseconds, a timer delay of 600 nanoseconds
will be set ((7 - 6.4) * 1000).

Link: https://lore.kernel.org/r/20200421151424.32668-6-dgilbert@interlog.comSigned-off-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      a2aede97
    • Douglas Gilbert's avatar
      scsi: scsi_debug: Weaken rwlock around ramdisk access · 67da413f
      Douglas Gilbert authored 
      The design of this driver is to do any ramdisk access on the same thread
that invoked the queuecommand() call. That is assumed to be user space
context. The command duration is implemented by setting the delay with a
high resolution timer. The hr timer's callback may well be in interrupt
context, but it doesn't touch the ramdisk. So try removing the
_irqsave()/_irqrestore() portion on the read-write lock that protects
ramdisk access.

Link: https://lore.kernel.org/r/20200421151424.32668-5-dgilbert@interlog.comSigned-off-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      67da413f
    • Douglas Gilbert's avatar
      scsi: scsi_debug: Implement VERIFY(10), add VERIFY(16) · c3e2fe92
      Douglas Gilbert authored 
      With the addition of the per_host_store option, the ability to check
whether two different ramdisk images are the same or not becomes
practical. Prior to this patch VERIFY(10) always returned true (i.e.  the
SCSI GOOD status) without checking. This option adds support for BYTCHK
equal to 0, 1 and 3. If the comparison fails, then a sense key of
MISCOMPARE is returned as per the T10 standards. Also add support for the
VERIFY(16) command.

Link: https://lore.kernel.org/r/20200421151424.32668-4-dgilbert@interlog.comReviewed-by: default avatarHannes Reinecke <hare@suse.de>
Signed-off-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      c3e2fe92
    • Douglas Gilbert's avatar
      scsi: scsi_debug: Add per_host_store option · 87c715dc
      Douglas Gilbert authored 
      The scsi_debug driver has always been restricted to using one ramdisk image
(or none) 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
changes the way a following write to the add_host parameter (or an add_host
in the module/driver invocation) operates.  For each new host that is
created while per_host_store is true, a new store (of dev-size_mb MiB) is
created and associated with all the LUs that belong to that new host. The
user (who will need root permissions) needs to take care not to exhaust all
the machine's available RAM.

One reason for doing this is to check that (partial) disk to disk copies
based on scsi_debug devices have actually copied accurately. To test this
the add_host=<n> parameter where <n> is 2 or greater can be used when the
scsi_debug module is loaded. Let us assume that /dev/sdb and /dev/sg1 are
the same scsi_debug device, while /dev/sdc and /dev/sg2 are the same
scsi_debug device. With per_host_store=1 add_host=2 they will have
different ramdisk images. Then the following pseudocode could be executed
to check if the 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).

[mkp: use kstrtobool()]

Link: https://lore.kernel.org/r/20200421151424.32668-3-dgilbert@interlog.comSigned-off-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      87c715dc
    • Douglas Gilbert's avatar
      scsi: scsi_debug: Randomize command completion time · 0c4bc91d
      Douglas Gilbert authored 
      Add a new command line option (e.g. random=1) and sysfs attribute that
causes subsequent command completion times to be between the current
command delay setting and 0. A uniformly distributed 32 bit, kernel
provided integer is used for this purpose.

Since the existing 'delay' whose units are jiffies (typically milliseconds)
and 'ndelay' (units: nanoseconds) options (and sysfs attributes) span a
range greater than 32 bits, some scaling is required.

The purpose of this patch is to widen the range of testing cases that are
visited in long running tests. Put simply: rarely struct race conditions
are more likely to be found when this facility is used.

The default is the previous case in which all command completions were
roughly equal to (if not, slightly longer) than the value given by the
'delay' or 'ndelay' settings (or their defaults).  This option's default is
equivalent to setting 'random=0' .

[mkp: use kstrtobool()]

Link: https://lore.kernel.org/r/20200421151424.32668-2-dgilbert@interlog.comReviewed-by: default avatarHannes Reinecke <hare@suse.de>
Signed-off-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      0c4bc91d
  3. 30 Apr, 2020 4 commits
  5. 27 Apr, 2020 7 commits
  7. 24 Apr, 2020 23 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7