async pass(4) patches available

[Fabian Keil]

"Kenneth D. Merry" <ken at FreeBSD.ORG> wrote:

> On Tue, Apr 07, 2015 at 13:16:04 +0200, Fabian Keil wrote:
> > "Kenneth D. Merry" <ken at FreeBSD.ORG> wrote:
> > 
> > > On Mon, Apr 06, 2015 at 15:39:56 +0200, Fabian Keil wrote:
> > > > "Kenneth D. Merry" <ken at FreeBSD.ORG> wrote:
> > > > 
> > > > > I have put patches to add an asynchronous interface to the
> > > > > pass(4) driver and add a new camdd(8) utility here:
> > > > > 
> > > > > FreeBSD/head as of SVN revision 280857:
> > > > > 
> > > > > http://people.freebsd.org/~ken/async_pass.head.20150330.1.txt
> > > > [...]
> > > > > Comments and testing are welcome!  As I said, camdd(8) in
> > > > > particular is a work in progress.  It could use some cleanup and
> > > > > there are some more useful features that could be added there.
> > > > 
> > > > I've been using the patch for a couple of days on an amd64 system
> > > > based on 11.0-CURRENT r280952 and didn't notice any obvious
> > > > regressions using the system as usual.
> > [...] 
> > > > I also tried to test camdd, but didn't get it to work.
> > > > Some failed attempts:
> > > > 
> > > > [fk at kendra ~]$ sudo camdd -i pass=da0,bs=65536 -o file=blafsel.img
> > > > (pass2:umass-sim0:0:0:0): READ(6). CDB: 08 00 00 00 80 00 
> > > > (pass2:umass-sim0:0:0:0): CAM status: CCB request completed with an
> > > > error 13 bytes read from pass2
> > > > 13 bytes written to blafsel.img
> > > > 20.3203 seconds elapsed
> > > > 0.00 MB/sec
> > > > [fk at kendra ~]$ sudo hd blafsel.img 
> > > > 00000000  55 53 42 53 d9 02 00 00  00 00 01 00 01
> > > > |USBS.........| 0000000d
> > > > [fk at kendra ~]$ sudo dd if=/dev/da0 bs=1k count=1  | hd | head -n 1
> > > > 1+0 records in
> > > > 1+0 records out
> > > > 1024 bytes transferred in 0.000603 secs (1697756 bytes/sec)
> > > > 00000000  fc 31 c0 8e c0 8e d8 8e  d0 bc 00 0e be 1a 7c bf
> > > > |.1............|.|
> > > 
> > > One possibility is that the device doesn't support 6-byte read/write
> > > requests.  The da(4) driver has quirk entries and code to figure
> > > that out and default to 10-byte read/write requests, but camdd(8)
> > > doesn't have anything like that yet.
> > > 
> > > I've attached patches to camdd that allow you to specify a minimum
> > > command size.  So, apply the patches, rebuild camdd, and try this:
> > > 
> > > # sudo camdd -i pass=da0,bs=65536,mcs=10 -o file=blafsel.img
> > > 
> > > We'll see if that helps.  I'm not sure why you were even able to get
> > > 13 bytes back.  That is very strange.
> > 
> > With the patch, reading from da0 seems to work until the end,
> > but again only 13 bytes are written out when writing to a file:
> > 
> > [fk at kendra ~]$ sudo camdd -i pass=da0,bs=65536,mcs=10 -o
> > file=blafsel.img (pass2:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 78
> > a8 00 00 00 00 00 (pass2:umass-sim0:0:0:0): CAM status: CCB request
> > completed with an error 4048551936 bytes read from pass2
> > 13 bytes written to blafsel.img
> > 127.6488 seconds elapsed
> > 0.00 MB/sec
> 
> Did the file exist before running that command?  If so, camdd will look
> at the file size and not write any more than the current file size.

That was probably it, at least I couldn't reproduce the problem
with a new file a few minutes ago:

[fk at kendra ~]$ sudo camdd -i pass=da0,bs=65536,mcs=10 -o file=/dpool/scratch/new-file.img  
(pass2:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 78 a8 00 00 00 00 00 
(pass2:umass-sim0:0:0:0): CAM status: CCB request completed with an error
4048551936 bytes read from pass2
4048551936 bytes written to /dpool/scratch/new-file.img
127.3009 seconds elapsed
30.33 MB/sec

and with an existing file camdd indeed behaved like you described:

[fk at kendra ~]$ truncate -s 100 /dpool/scratch/small-file
[fk at kendra ~]$ sudo camdd -i pass=da0,bs=65536,mcs=10 -o file=/dpool/scratch/small-file  
(pass2:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 78 a8 00 00 00 00 00 
(pass2:umass-sim0:0:0:0): CAM status: CCB request completed with an error
4048551936 bytes read from pass2
100 bytes written to /dpool/scratch/small-file
128.4956 seconds elapsed
0.00 MB/sec

> Thank you for testing it!

No problem.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20150407/fa206056/attachment.sig>