From owner-freebsd-current@FreeBSD.ORG Mon Apr 6 13:49:04 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADAA1AAA for ; Mon, 6 Apr 2015 13:49:04 +0000 (UTC) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.29.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D4D9A69 for ; Mon, 6 Apr 2015 13:49:03 +0000 (UTC) Received: from [84.44.155.155] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1Yf7Gk-0002w2-BN for freebsd-current@freebsd.org; Mon, 06 Apr 2015 15:40:50 +0200 Date: Mon, 6 Apr 2015 15:39:56 +0200 From: Fabian Keil To: freebsd-current@freebsd.org Subject: Re: async pass(4) patches available Message-ID: <2147223b.4518a234@fabiankeil.de> In-Reply-To: <20150330222358.GA46342@mithlond.kdm.org> References: <20150330222358.GA46342@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/OFl2=gJfwvBdtvIL1mNOVB+"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 13:49:04 -0000 --Sig_/OFl2=gJfwvBdtvIL1mNOVB+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Kenneth D. Merry" wrote: > I have put patches to add an asynchronous interface to the pass(4) driver > and add a new camdd(8) utility here: >=20 > FreeBSD/head as of SVN revision 280857: >=20 > 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. Scrubbing a pool once revealed checksum errors which I haven't seen before: [fk@kendra ~]$ zpool status -v dpool pool: dpool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://illumos.org/msg/ZFS-8000-9P scan: scrub repaired 0 in 1h52m with 0 errors on Thu Apr 2 13:01:44 2015 config: NAME STATE READ WRITE CKSUM dpool ONLINE 0 0 0 gpt/dpool-ada0.eli ONLINE 0 0 6 errors: No known data errors Apr 2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB= : 60 30 17 61 55 40 31 00 00 00 00 00 Apr 2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): CAM status: ATA Status= Error Apr 2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): ATA status: 51 (DRDY S= ERV ERR), error: 40 (UNC ) Apr 2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): RES: 51 40 3e 61 55 40= 31 00 00 00 00 Apr 2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): Error 5, Retries exhau= sted Apr 2 12:31:34 kendra kernel: GEOM_ELI: g_eli_read_done() failed gpt/dpool= -ada0.eli[READ(offset=3D414970949120, length=3D24576)] However the issue doesn't seem to be (easily) reproducible and could be unrelated. I also tried to test camdd, but didn't get it to work. Some failed attempts: [fk@kendra ~]$ sudo camdd -i pass=3Dda0,bs=3D65536 -o file=3Dblafsel.img (pass2:umass-sim0:0:0:0): READ(6). CDB: 08 00 00 00 80 00=20 (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=20 00000000 55 53 42 53 d9 02 00 00 00 00 01 00 01 |USBS.........| 0000000d [fk@kendra ~]$ sudo dd if=3D/dev/da0 bs=3D1k count=3D1 | 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............= |.| Trying the block size suggested in the manual result in: [fk@kendra ~]$ sudo camdd -i pass=3Dda0,bs=3D1M -o file=3Dblafsel.img camdd: camdd_pass_run: error sending CAMIOQUEUE ioctl to pass2: Invalid arg= ument camdd: camdd_pass_run: CCB address is 0x80250e420: Invalid argument 0 bytes read from pass2 0 bytes written to blafsel.img 0.0007 seconds elapsed 0.00 MB/sec Apr 5 19:08:20 kendra kernel: (pass2:umass-sim0:0:0:0): passmemsetup: data= length 1048576 > max allowed 65536 bytes Fabian --Sig_/OFl2=gJfwvBdtvIL1mNOVB+ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUijKkACgkQBYqIVf93VJ3JmgCePvwjyJJ8mPouBgeqOZCZxdsk e0gAoMR6v4SDN7uWsiqtuoZP3Tilt5KV =B1g1 -----END PGP SIGNATURE----- --Sig_/OFl2=gJfwvBdtvIL1mNOVB+--