Date: Tue, 7 Apr 2015 10:31:13 -0600 From: "Kenneth D. Merry" <ken@FreeBSD.ORG> To: Fabian Keil <freebsd-listen@fabiankeil.de> Cc: freebsd-current@freebsd.org Subject: Re: async pass(4) patches available Message-ID: <20150407163113.GA7762@mithlond.kdm.org> In-Reply-To: <00653530.74872429@fabiankeil.de> References: <20150330222358.GA46342@mithlond.kdm.org> <2147223b.4518a234@fabiankeil.de> <20150406220744.GA92212@mithlond.kdm.org> <00653530.74872429@fabiankeil.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 07, 2015 at 13:16:04 +0200, Fabian Keil wrote: > "Kenneth D. Merry" <ken@FreeBSD.ORG> wrote: > > > On Mon, Apr 06, 2015 at 15:39:56 +0200, Fabian Keil wrote: > > > "Kenneth D. Merry" <ken@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@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@kendra ~]$ sudo hd blafsel.img > > > 00000000 55 53 42 53 d9 02 00 00 00 00 01 00 01 > > > |USBS.........| 0000000d > > > [fk@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@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. If the file doesn't exist, it'll stop writing when it reaches the end of the input, or it gets a write error, or it reaches the specified I/O limit (-m argument). It also looks like there is a bug; the command above is attempting to read 0 bytes starting from one sector beyond the last logical block. > [fk@kendra ~]$ diskinfo -v /dev/da0 > /dev/da0 > 512 # sectorsize > 4048551936 # mediasize in bytes (3.8G) > 7907328 # mediasize in sectors > 0 # stripesize > 0 # stripeoffset > 492 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > AA00000000000958 # Disk ident. > > It works as expected when writing to stdout, though, so this is > probably just a camdd-internal issue: > > [fk@kendra ~]$ sudo camdd -i pass=da0,bs=65536,mcs=10 -o file=- > /dpool/scratch/blafasel.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 - > 128.7222 seconds elapsed > 29.99 MB/sec Ahh, yes, that is what I would expect. > [fk@kendra ~]$ sudo dd if=/dev/da0 bs=65536 of=/dpool/scratch/blafasel-dd.img > 61776+0 records in > 61776+0 records out > 4048551936 bytes transferred in 134.993030 secs (29990822 bytes/sec) > > [fk@kendra ~]$ sha1 /dpool/scratch/blafasel*.img > SHA1 (/dpool/scratch/blafasel-dd.img) = 12d1d9e82f840a6c6485ffcdb1fbf780266ed266 > SHA1 (/dpool/scratch/blafasel.img) = 12d1d9e82f840a6c6485ffcdb1fbf780266ed266 > > Looks good to me. Great! I'll see if I can fix the bug that is causing the zero length read at the end. Thank you for testing it! Ken -- Kenneth Merry ken@FreeBSD.ORG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150407163113.GA7762>