From owner-freebsd-fs@FreeBSD.ORG Sun Jul 31 20:01:35 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8327B106566B; Sun, 31 Jul 2011 20:01:35 +0000 (UTC) (envelope-from prvs=1193afe4ca=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 9ADD78FC0A; Sun, 31 Jul 2011 20:01:34 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 31 Jul 2011 20:50:29 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 31 Jul 2011 20:50:29 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014407264.msg; Sun, 31 Jul 2011 20:50:27 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1193afe4ca=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <04C305AE5F184C6AAC2A67CE23184013@multiplay.co.uk> From: "Steven Hartland" To: "David P Discher" References: <0D449EC916264947AB31AA17F870EA7A@multiplay.co.uk> <4E3013DF.10803@FreeBSD.org> <3D6CEB50BEDD4ACE96FD35C4D085618A@multiplay.co.uk> <4E301C55.7090105@FreeBSD.org> <5C84E7C8452E489C8CA738294F5EBB78@multiplay.co.uk> <4E301F10.6060708@FreeBSD.org> <63705B5AEEAD4BB88ADB9EF770AB6C76@multiplay.co.uk> <4E302204.2030009@FreeBSD.org> <6703F0BB-D4FC-4417-B519-CAFC62E5BC39@bitgravity.com> Date: Sun, 31 Jul 2011 20:50:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-fs@FreeBSD.org, Andriy Gapon Subject: Re: zfs process hang on pool access X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 20:01:35 -0000 Is there a PR related to this so we can track progress. Having to reboot machines every 100+ days to ensure they don't break is a bit of a PITA when you've got hundreds of machines :( ----- Original Message ----- From: "David P Discher" To: "Steven Hartland" Cc: ; "Andriy Gapon" Sent: Wednesday, July 27, 2011 9:41 PM Subject: Re: zfs process hang on pool access The way I found this was breaking into the debugger, do some back traces, continue, break in again, do some more back traces on the hung processes ... see what is going on, then walk through the code. Then what I had specific loops and code locations, asking the higher powers of the freebsd kernel world. ... ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Sun Jul 31 20:29:13 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFC57106566C; Sun, 31 Jul 2011 20:29:13 +0000 (UTC) (envelope-from dpd@bitgravity.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id B152A8FC0A; Sun, 31 Jul 2011 20:29:13 +0000 (UTC) Received: by pzk5 with SMTP id 5so30362568pzk.17 for ; Sun, 31 Jul 2011 13:29:13 -0700 (PDT) Received: by 10.68.31.130 with SMTP id a2mr872036pbi.275.1312142781276; Sun, 31 Jul 2011 13:06:21 -0700 (PDT) Received: from [10.1.10.12] (173-13-188-46-sfba.hfc.comcastbusiness.net [173.13.188.46]) by mx.google.com with ESMTPS id i9sm4682298pbk.36.2011.07.31.13.06.19 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 31 Jul 2011 13:06:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: David P Discher X-Priority: 3 In-Reply-To: <04C305AE5F184C6AAC2A67CE23184013@multiplay.co.uk> Date: Sun, 31 Jul 2011 13:06:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D893A9B-2CD9-40EB-B4A2-5DBCBB72C62E@bitgravity.com> References: <0D449EC916264947AB31AA17F870EA7A@multiplay.co.uk> <4E3013DF.10803@FreeBSD.org> <3D6CEB50BEDD4ACE96FD35C4D085618A@multiplay.co.uk> <4E301C55.7090105@FreeBSD.org> <5C84E7C8452E489C8CA738294F5EBB78@multiplay.co.uk> <4E301F10.6060708@FreeBSD.org> <63705B5AEEAD4BB88ADB9EF770AB6C76@multiplay.co.uk> <4E302204.2030009@FreeBSD.org> <6703F0BB-D4FC-4417-B519-CAFC62E5BC39@bitgravity.com> <04C305AE5F184C6AAC2A67CE23184013@multiplay.co.uk> To: "Steven Hartland" X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@FreeBSD.org, Andriy Gapon Subject: Re: zfs process hang on pool access X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 20:29:14 -0000 I've actually found a second issue that my working theory is related to = the *fix* of LBOLT, in zio_wait()/txg_delay() when calling = _cv_wait()/_cv_timedwait(). This maybe aggravated by setting = vfs.zfs.txg.timeout=3D1. And in fact these functions are using using = LBOLT with signed 32bit ints.=20 I got some cores, and ideas, and will dig into the debugging this week. = And of course will post my findings (and pleads for help) here on = freebsd-fs@. Rolling back the two patches I posted early for the 26+ day and 106+ = days bugs, seemed to avoid the new issue. --- David P. Discher dpd@bitgravity.com * AIM: bgDavidDPD BITGRAVITY * http://www.bitgravity.com On Jul 31, 2011, at 12:50 PM, Steven Hartland wrote: > Is there a PR related to this so we can track progress. Having to = reboot machines > every 100+ days to ensure they don't break is a bit of a PITA when = you've got hundreds > of machines :( >=20 > ----- Original Message ----- From: "David P Discher" = > To: "Steven Hartland" > Cc: ; "Andriy Gapon" > Sent: Wednesday, July 27, 2011 9:41 PM > Subject: Re: zfs process hang on pool access >=20 >=20 > The way I found this was breaking into the debugger, do some back = traces, continue, break in again, do some more back traces on the hung = processes ... see what is going on, then walk through the code. >=20 > Then what I had specific loops and code locations, asking the higher = powers of the freebsd kernel world. >=20 From owner-freebsd-fs@FreeBSD.ORG Sun Jul 31 22:10:51 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E70C1065673; Sun, 31 Jul 2011 22:10:51 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id 309058FC15; Sun, 31 Jul 2011 22:10:51 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 89F6D18BABE; Mon, 1 Aug 2011 00:10:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ms3WFko5bgap; Mon, 1 Aug 2011 00:10:46 +0200 (CEST) Received: from [10.9.8.3] (chello085216231078.chello.sk [85.216.231.78]) by mail.vx.sk (Postfix) with ESMTPSA id 3F0BE18BAB1; Mon, 1 Aug 2011 00:10:46 +0200 (CEST) Message-ID: <4E35D2E5.4020108@FreeBSD.org> Date: Mon, 01 Aug 2011 00:10:45 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: David P Discher References: <0D449EC916264947AB31AA17F870EA7A@multiplay.co.uk> <4E3013DF.10803@FreeBSD.org> <3D6CEB50BEDD4ACE96FD35C4D085618A@multiplay.co.uk> <4E301C55.7090105@FreeBSD.org> <5C84E7C8452E489C8CA738294F5EBB78@multiplay.co.uk> <4E301F10.6060708@FreeBSD.org> <63705B5AEEAD4BB88ADB9EF770AB6C76@multiplay.co.uk> <4E302204.2030009@FreeBSD.org> <6703F0BB-D4FC-4417-B519-CAFC62E5BC39@bitgravity.com> <04C305AE5F184C6AAC2A67CE23184013@multiplay.co.uk> <3D893A9B-2CD9-40EB-B4A2-5DBCBB72C62E@bitgravity.com> In-Reply-To: <3D893A9B-2CD9-40EB-B4A2-5DBCBB72C62E@bitgravity.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@FreeBSD.org, Andriy Gapon Subject: Re: zfs process hang on pool access X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 22:10:51 -0000 I walked through all occurences of ddi_get_lbolt() in the ZFS code and this is the only place where it is incorrectly initialized. This is how it should look like. =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c (revision 224527) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c (working copy) @@ -488,7 +488,7 @@ txg_delay(dsl_pool_t *dp, uint64_t txg, int ticks) { tx_state_t *tx = &dp->dp_tx; - int timeout = ddi_get_lbolt() + ticks; + clock_t timeout = ddi_get_lbolt() + ticks; /* don't delay if this txg could transition to quiesing immediately */ if (tx->tx_open_txg > txg || Dňa 31. 7. 2011 22:06, David P Discher wrote / napísal(a): > I've actually found a second issue that my working theory is related to the *fix* of LBOLT, in zio_wait()/txg_delay() when calling _cv_wait()/_cv_timedwait(). This maybe aggravated by setting vfs.zfs.txg.timeout=1. And in fact these functions are using using LBOLT with signed 32bit ints. > > I got some cores, and ideas, and will dig into the debugging this week. And of course will post my findings (and pleads for help) here on freebsd-fs@. > > Rolling back the two patches I posted early for the 26+ day and 106+ days bugs, seemed to avoid the new issue. > > --- > David P. Discher > dpd@bitgravity.com * AIM: bgDavidDPD > BITGRAVITY * http://www.bitgravity.com > > On Jul 31, 2011, at 12:50 PM, Steven Hartland wrote: > >> Is there a PR related to this so we can track progress. Having to reboot machines >> every 100+ days to ensure they don't break is a bit of a PITA when you've got hundreds >> of machines :( >> >> ----- Original Message ----- From: "David P Discher" >> To: "Steven Hartland" >> Cc: ; "Andriy Gapon" >> Sent: Wednesday, July 27, 2011 9:41 PM >> Subject: Re: zfs process hang on pool access >> >> >> The way I found this was breaking into the debugger, do some back traces, continue, break in again, do some more back traces on the hung processes ... see what is going on, then walk through the code. >> >> Then what I had specific loops and code locations, asking the higher powers of the freebsd kernel world. >> > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Sun Jul 31 23:33:19 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F809106566C; Sun, 31 Jul 2011 23:33:19 +0000 (UTC) (envelope-from prvs=1193afe4ca=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6785B8FC0A; Sun, 31 Jul 2011 23:33:17 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Mon, 01 Aug 2011 00:32:45 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 01 Aug 2011 00:32:45 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014409919.msg; Mon, 01 Aug 2011 00:32:45 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1193afe4ca=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <0E851F439C384186A1D44A347C19A7D7@multiplay.co.uk> From: "Steven Hartland" To: "Martin Matuska" , "David P Discher" References: <0D449EC916264947AB31AA17F870EA7A@multiplay.co.uk> <4E3013DF.10803@FreeBSD.org> <3D6CEB50BEDD4ACE96FD35C4D085618A@multiplay.co.uk> <4E301C55.7090105@FreeBSD.org> <5C84E7C8452E489C8CA738294F5EBB78@multiplay.co.uk> <4E301F10.6060708@FreeBSD.org> <63705B5AEEAD4BB88ADB9EF770AB6C76@multiplay.co.uk> <4E302204.2030009@FreeBSD.org> <6703F0BB-D4FC-4417-B519-CAFC62E5BC39@bitgravity.com> <04C305AE5F184C6AAC2A67CE23184013@multiplay.co.uk> <3D893A9B-2CD9-40EB-B4A2-5DBCBB72C62E@bitgravity.com> <4E35D2E5.4020108@FreeBSD.org> Date: Mon, 1 Aug 2011 00:33:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-fs@FreeBSD.org, Andriy Gapon Subject: Re: zfs process hang on pool access X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 23:33:19 -0000 ----- Original Message ----- From: "Martin Matuska" >I walked through all occurences of ddi_get_lbolt() in the ZFS code and > this is the only place where it is incorrectly initialized. > This is how it should look like. > > =================================================================== > --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c (revision 224527) > +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c (working copy) > @@ -488,7 +488,7 @@ > txg_delay(dsl_pool_t *dp, uint64_t txg, int ticks) > { > tx_state_t *tx = &dp->dp_tx; > - int timeout = ddi_get_lbolt() + ticks; > + clock_t timeout = ddi_get_lbolt() + ticks; So you recon that one line will fix the 100+ days overflow David's talking about? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 11:07:07 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20D431065670 for ; Mon, 1 Aug 2011 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0F2308FC12 for ; Mon, 1 Aug 2011 11:07:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p71B77W0014558 for ; Mon, 1 Aug 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p71B76Un014556 for freebsd-fs@FreeBSD.org; Mon, 1 Aug 2011 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Aug 2011 11:07:06 GMT Message-Id: <201108011107.p71B76Un014556@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 11:07:07 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159233 fs [ext2fs] [patch] fs/ext2fs: finish reallocblk implemen o kern/159232 fs [ext2fs] [patch] fs/ext2fs: merge ext2_readwrite into o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs [amd] amd(8) ICMP storm and unkillable process. o kern/158711 fs [ffs] [panic] panic in ffs_blkfree and ffs_valloc o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157728 fs [zfs] zfs (v28) incremental receive may leave behind t o kern/157722 fs [geli] unable to newfs a geli encrypted partition o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156933 fs [zfs] ZFS receive after read on readonly=on filesystem o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156168 fs [nfs] [panic] Kernel panic under concurrent access ove o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs o kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 o kern/154447 fs [zfs] [panic] Occasional panics - solaris assert somew p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153847 fs [nfs] [panic] Kernel panic from incorrect m_free in nf o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small p kern/152488 fs [tmpfs] [patch] mtime of file updated when only inode o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o kern/151845 fs [smbfs] [patch] smbfs should be upgraded to support Un o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/150207 fs zpool(1): zpool import -d /dev tries to open weird dev o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o bin/148296 fs [zfs] [loader] [patch] Very slow probe in /usr/src/sys o kern/148204 fs [nfs] UDP NFS causes overload o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147790 fs [zfs] zfs set acl(mode|inherit) fails on existing zfs o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an o bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs f kern/130133 fs [panic] [zfs] 'kmem_map too small' caused by make clea o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs f kern/127375 fs [zfs] If vm.kmem_size_max>"1073741823" then write spee o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi f kern/126703 fs [panic] [zfs] _mtx_lock_sleep: recursed on non-recursi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files f sparc/123566 fs [zfs] zpool import issue: EOVERFLOW o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/120210 fs [zfs] [panic] reboot after panic: solaris assert: arc_ o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/33464 fs [ufs] soft update inconsistencies after system crash o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 239 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 12:56:03 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F35FF106566B; Mon, 1 Aug 2011 12:56:02 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id 84F338FC0A; Mon, 1 Aug 2011 12:56:02 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 7636618CC71; Mon, 1 Aug 2011 14:56:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XJhVVyT6C9T3; Mon, 1 Aug 2011 14:55:59 +0200 (CEST) Received: from [10.9.8.3] (chello085216231078.chello.sk [85.216.231.78]) by mail.vx.sk (Postfix) with ESMTPSA id 4335018CC6A; Mon, 1 Aug 2011 14:55:59 +0200 (CEST) Message-ID: <4E36A25F.7000000@FreeBSD.org> Date: Mon, 01 Aug 2011 14:55:59 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Steven Hartland References: <0D449EC916264947AB31AA17F870EA7A@multiplay.co.uk> <4E3013DF.10803@FreeBSD.org> <3D6CEB50BEDD4ACE96FD35C4D085618A@multiplay.co.uk> <4E301C55.7090105@FreeBSD.org> <5C84E7C8452E489C8CA738294F5EBB78@multiplay.co.uk> <4E301F10.6060708@FreeBSD.org> <63705B5AEEAD4BB88ADB9EF770AB6C76@multiplay.co.uk> <4E302204.2030009@FreeBSD.org> <6703F0BB-D4FC-4417-B519-CAFC62E5BC39@bitgravity.com> <04C305AE5F184C6AAC2A67CE23184013@multiplay.co.uk> <3D893A9B-2CD9-40EB-B4A2-5DBCBB72C62E@bitgravity.com> <4E35D2E5.4020108@FreeBSD.org> <0E851F439C384186A1D44A347C19A7D7@multiplay.co.uk> In-Reply-To: <0E851F439C384186A1D44A347C19A7D7@multiplay.co.uk> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@FreeBSD.org, Andriy Gapon Subject: Re: zfs process hang on pool access X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 12:56:03 -0000 Dňa 1. 8. 2011 1:33, Steven Hartland wrote / napísal(a): > ----- Original Message ----- From: "Martin Matuska" > > >> I walked through all occurences of ddi_get_lbolt() in the ZFS code and >> this is the only place where it is incorrectly initialized. >> This is how it should look like. >> >> =================================================================== >> --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c (revision >> 224527) >> +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c (working copy) >> @@ -488,7 +488,7 @@ >> txg_delay(dsl_pool_t *dp, uint64_t txg, int ticks) >> { >> tx_state_t *tx = &dp->dp_tx; >> - int timeout = ddi_get_lbolt() + ticks; >> + clock_t timeout = ddi_get_lbolt() + ticks; > > So you recon that one line will fix the 100+ days overflow David's > talking about? No, this bug causes that after 28,5 days of uptime this function won't delay txg sync threads anymore (ddi_get_lbolt() will be always larger than timeout).This may lead to a slowdown of writes. -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 16:49:06 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6D421065670 for ; Mon, 1 Aug 2011 16:49:06 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 49EE38FC18 for ; Mon, 1 Aug 2011 16:49:06 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qnvfs-0000DB-Us for freebsd-fs@freebsd.org; Mon, 01 Aug 2011 18:49:04 +0200 Received: from ib-jtotz.ib.ic.ac.uk ([155.198.110.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Aug 2011 18:49:04 +0200 Received: from jtotz by ib-jtotz.ib.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Aug 2011 18:49:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Mon, 01 Aug 2011 17:48:51 +0100 Lines: 71 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ib-jtotz.ib.ic.ac.uk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 Subject: zfs hang on zfs access X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:49:06 -0000 Hi! Lots of processes hang when accessing one specific zfs data set. All other sets are fine. This looks similar to the pool-hang report by Steven Hartland last week, but the machine in question has no high uptime: (Pasted as quote to avoid line-break) > last pid: 274; load averages: 0.00, 0.48, 1.21 up 6+13:06:28 17:35:29 > 71 processes: 1 running, 70 sleeping > CPU: 0.2% user, 0.0% nice, 0.2% system, 0.0% interrupt, 99.6% idle > Mem: 26M Active, 18M Inact, 5018M Wired, 1512K Cache, 597M Buf, 617M Free > Swap: 4096M Total, 27M Used, 4069M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 274 root 1 44 0 9376K 2864K CPU0 1 0:00 0.29% top > 99902 root 1 44 0 29152K 5440K h->has 1 0:00 0.00% smbd > 99922 root 1 44 0 29152K 5056K h->has 1 0:00 0.00% smbd > 99995 root 1 44 0 29152K 5072K zfs 1 0:00 0.00% smbd > 99958 root 1 44 0 29152K 5056K zfsvfs 1 0:00 0.00% smbd > 99976 root 1 45 0 29152K 4824K zfs 1 0:00 0.00% smbd > 99946 root 1 44 0 29152K 4692K zfsvfs 1 0:00 0.00% smbd > 99949 root 1 44 0 29152K 4700K zfsvfs 1 0:00 0.00% smbd > 205 root 1 44 0 29152K 4800K lockf 1 0:00 0.00% smbd > 219 root 1 44 0 29152K 4748K lockf 1 0:00 0.00% smbd > 99932 root 1 44 0 29152K 4704K zfsvfs 1 0:00 0.00% smbd > 99921 root 1 44 0 29152K 4584K zfs 1 0:00 0.00% smbd > 99951 root 1 44 0 29152K 4688K h->has 1 0:00 0.00% smbd > 229 root 1 44 0 29152K 4760K lockf 1 0:00 0.00% smbd > 218 root 1 44 0 29152K 4720K lockf 1 0:00 0.00% smbd > 99952 root 1 44 0 29152K 4688K h->has 1 0:00 0.00% smbd > 99956 root 1 44 0 28816K 4212K zfs 1 0:00 0.00% smbd > 99978 root 1 44 0 29152K 4740K zfs 1 0:00 0.00% smbd > 199 backuppc 1 44 0 12608K 2820K h->has 1 0:00 0.00% perl5.8.9 > 99945 root 1 44 0 28816K 4212K zfs 1 0:00 0.00% smbd > 105 root 1 44 0 29152K 4652K zfs 1 0:00 0.00% smbd > 181 root 1 44 0 28816K 4160K zfs 1 0:00 0.00% smbd > 178 root 1 44 0 28816K 4156K zfs 1 0:00 0.00% smbd > 99950 root 1 44 0 28816K 4208K zfs 1 0:00 0.00% smbd > 257 jo 1 52 0 8252K 1564K zfs 1 0:00 0.00% ls > 99929 root 1 44 0 28816K 4204K zfs 1 0:00 0.00% smbd > 108 root 1 45 0 29152K 4620K zfs 1 0:00 0.00% smbd > 177 root 1 76 0 17976K 2308K tx->tx 1 0:00 0.00% zfs > 136 root 1 76 0 2764K 1048K wait 0 0:00 0.00% lockf I snipped off the ones that look harmless, i.e. the above processes look strange to me. All the smbd are a result of Windows laptops trying to access the share that lives on the hang-causing zfs dataset. > #procstat -kk 257 > PID TID COMM TDNAME KSTACK > 257 100335 ls - mi_switch+0x1c2 sleepq_switch+0xdc sleepq_wait+0x45 __lockmgr_args+0x8e2 vop_stdlock+0x51 VOP_LOCK1_APV+0x55 _vn_lock+0x48 cache_lookup+0x63f vfs_cache_lookup+0xad VOP_LOOKUP_APV+0x53 lookup+0x624 namei+0x597 vn_open_cred+0x340 vn_open+0x1c kern_openat+0x163 kern_open+0x19 open+0x18 syscallenter+0x2fe > #procstat -kk 136 > PID TID COMM TDNAME KSTACK > 136 100264 lockf - mi_switch+0x1c2 sleepq_switch+0xdc sleepq_catch_signals+0x57 sleepq_wait_sig+0xc _sleep+0x26e kern_wait+0xeda wait4+0x37 syscallenter+0x2fe syscall+0x41 Xfast_syscall+0xe2 This is on: > FreeBSD XXX 8.2-STABLE FreeBSD 8.2-STABLE #0 r224227: Wed Jul 20 16:55:23 BST 2011 root@XXX:/usr/obj/usr/src/sys/GENERIC amd64 Any zfs list or similar hangs as well. Last night's scrub finished without any errors. It is likely that the hang occured during an hourly snapshot (no more log entries about recent snapshots). Ideas? Johannes From owner-freebsd-fs@FreeBSD.ORG Tue Aug 2 05:14:34 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21BFF106564A; Tue, 2 Aug 2011 05:14:34 +0000 (UTC) (envelope-from alex@zagrebin.ru) Received: from mail.zagrebin.ru (gw.zagrebin.ru [91.215.205.128]) by mx1.freebsd.org (Postfix) with ESMTP id B2F9F8FC08; Tue, 2 Aug 2011 05:14:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zagrebin.ru; s=mail; h=Content-Type:MIME-Version:Message-ID:Subject:Cc:To:From:Date; bh=l7yZn36CRGax4l5waVH//ZhZ79VpBvJZKjOjtHhtzmg=; b=T6yHHvjevRSkSCf8Q5ickJh6X4gKgj3lC/Kc9QWpOrZEokA8WLF3ojTzi1H4tQrVgRybkxpvP1rer3EWolJ1zohzNTHchMZdn+LrLq/gB3txTRycr/8tomW0SPHAuGsy1lyMImPqrzoou4MTusYd2Gp4Ol/B75gmy3eIxgYpfgY=; Received: from alex by mail.zagrebin.ru with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qo6sx-0002SC-Je; Tue, 02 Aug 2011 08:47:19 +0400 Date: Tue, 2 Aug 2011 08:47:19 +0400 From: Alexander Zagrebin To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20110802044718.GA8838@gw.zagrebin.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: ZFS v28: kernel panics while reading an extended attribute X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 05:14:34 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! It seems, I've found a bug in the ZFS v28 on the latest stable: if we have a snapshot with some files having an extended attributes, then attempt to read an extended attributes's value leads to a well reproducible kernel panic. The part of backtrace follows: #6 0xffffffff804bbe44 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0xffffffff80950ea7 in zil_commit (zilog=0x0, foid=5795917) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c:1497 #8 0xffffffff80979e6b in zfs_freebsd_read (ap=Variable "ap" is not available.) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:622 #9 0xffffffff80979750 in zfs_getextattr (ap=0xffffff80dd5d8820) at vnode_if.h:384 #10 0xffffffff8038921b in extattr_get_vp (vp=0xffffff0056a01588, attrnamespace=1, attrname=0xffffff80dd5d89a0 "DOSATTRIB", data=Variable "data" is not available.) at vnode_if.h:1332 It seems that ZIL isn't available for snapshots, but zfs_freebsd_read doesn't check this when calling zil_commit. The attached patch fixes this issue. Can anybody confirm this? -- Alexander Zagrebin --NzB8fVQJ5HfG6fxh Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="patch-zfs_vnops.c" --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c.orig 2011-08-01 23:04:07.358173627 +0400 +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c 2011-08-02 00:10:02.674585604 +0400 @@ -618,7 +618,8 @@ zfs_read(vnode_t *vp, uio_t *uio, int io /* * If we're in FRSYNC mode, sync out this znode before reading it. */ - if (ioflag & FRSYNC || zfsvfs->z_os->os_sync == ZFS_SYNC_ALWAYS) + if (zfsvfs->z_log && + (ioflag & FRSYNC || zfsvfs->z_os->os_sync == ZFS_SYNC_ALWAYS)) zil_commit(zfsvfs->z_log, zp->z_id); /* --NzB8fVQJ5HfG6fxh-- From owner-freebsd-fs@FreeBSD.ORG Tue Aug 2 15:06:11 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6E74106566B; Tue, 2 Aug 2011 15:06:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A7C808FC0C; Tue, 2 Aug 2011 15:06:10 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA22003; Tue, 02 Aug 2011 18:06:08 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QoGXn-000HlP-Mw; Tue, 02 Aug 2011 18:06:07 +0300 Message-ID: <4E38125E.1040109@FreeBSD.org> Date: Tue, 02 Aug 2011 18:06:06 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Doug Barton , freebsd-ports@FreeBSD.org References: <4E345DBD.1090503@FreeBSD.org> <4E34B0BB.9050008@FreeBSD.org> <4E353A46.1050204@FreeBSD.org> <4E35A998.5060102@FreeBSD.org> <4E37F81F.7040902@FreeBSD.org> In-Reply-To: <4E37F81F.7040902@FreeBSD.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: portmaster, zfs metadata caching [Was: UPDATING 20110730] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:06:12 -0000 on 02/08/2011 16:14 Andriy Gapon said the following: > And now to my side of the problem. > While "profiling" pkg_info with ktrace I see getdirentries(2) calls sometimes > take quite a while. And since I have > 1000 ports all those calls do add up. > DTrace shows that the calls are quite fast (~0.3 ms) when there is no actual > disk access, but if it occurs then it introduces a delay on the orders of 1 - > 100 milliseconds. > I am really in doubts about what is happening here. It seems that all the > directory data isn't kept in ZFS ARC for long enough or is squeezed out of it by > some other data (without additional pressure it should easily fit into the ARC). > And also that somehow disk accesses have quite large latency. Although svc_t > according to iostat is smaller (5 - 10 ms). DTrace shows that the thread spends > the time in cv_wait. So it's possible that the scheduler is also involved here > as its decisions also may add a delay to when the thread becomes runnable again. Reporting further, just in case anyone follows this. (You may want to scroll down to my conclusions at the end of the message). I tracked my ZFS problem to my experiments with ZFS tuning. I limited my ARC size at some value that I considered to be large enough to cache my working sets of data and _metadata_. Little did I know that by default ZFS sets aside only 1/4th of ARC size for metadata. So this is already significantly smaller than I expected. Then it seems that a large piece of that metadata portion is permanently occupied by some non-evict-able data (not sure what it actually is, haven't tracked yet). In the end only a small portion of my ARC was available for holding the metadata which included the directory contents data. So this is what I had with the old settings: vfs.zfs.arc_meta_limit: 314572800 vfs.zfs.arc_meta_used: 401064272 and $ for i in $(jot 5) ; do /usr/bin/time -p pkg_info -O print/printme ; done The following installed package(s) has print/printme origin: real 12.55 user 0.02 sys 2.51 The following installed package(s) has print/printme origin: real 12.65 user 0.03 sys 1.99 The following installed package(s) has print/printme origin: real 10.57 user 0.02 sys 1.57 The following installed package(s) has print/printme origin: real 8.85 user 0.03 sys 0.17 The following installed package(s) has print/printme origin: real 9.28 user 0.02 sys 0.20 I think that you should get the picture. Now I have bumped the limit and this is what I had just right after doing it: vfs.zfs.arc_meta_limit: 717225984 vfs.zfs.arc_meta_used: 414439800 and $ for i in $(jot 5) ; do /usr/bin/time -p pkg_info -O print/printme ; done The following installed package(s) has print/printme origin: real 9.08 user 0.01 sys 0.18 The following installed package(s) has print/printme origin: real 7.48 user 0.04 sys 0.14 The following installed package(s) has print/printme origin: real 0.08 user 0.00 sys 0.07 The following installed package(s) has print/printme origin: real 0.95 user 0.03 sys 0.04 The following installed package(s) has print/printme origin: real 0.08 user 0.00 sys 0.07 Two runs to "warm up" the ARC and then everything works just perfect. I think that this is an important discovery for two reason: 1. I learned a new thing about ZFS ARC. 2. This problem demonstrates that portmaster currently does depend on a filesystem cache being able to hold a significant amount of ports/packages (meta)data. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Aug 2 18:01:27 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20FB41065670; Tue, 2 Aug 2011 18:01:27 +0000 (UTC) (envelope-from dpd@bitgravity.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id BED7E8FC15; Tue, 2 Aug 2011 18:01:26 +0000 (UTC) Received: by gwb15 with SMTP id 15so19715gwb.13 for ; Tue, 02 Aug 2011 11:01:26 -0700 (PDT) Received: by 10.142.118.23 with SMTP id q23mr3630206wfc.257.1312308085230; Tue, 02 Aug 2011 11:01:25 -0700 (PDT) Received: from netops-173.sfo1.bitgravity.com (netops-173.sfo1.bitgravity.com [209.131.110.173]) by mx.google.com with ESMTPS id e6sm55275pbm.55.2011.08.02.11.01.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Aug 2011 11:01:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: David P Discher In-Reply-To: <4E36A25F.7000000@FreeBSD.org> Date: Tue, 2 Aug 2011 11:01:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D449EC916264947AB31AA17F870EA7A@multiplay.co.uk> <4E3013DF.10803@FreeBSD.org> <3D6CEB50BEDD4ACE96FD35C4D085618A@multiplay.co.uk> <4E301C55.7090105@FreeBSD.org> <5C84E7C8452E489C8CA738294F5EBB78@multiplay.co.uk> <4E301F10.6060708@FreeBSD.org> <63705B5AEEAD4BB88ADB9EF770AB6C76@multiplay.co.uk> <4E302204.2030009@FreeBSD.org> <6703F0BB-D4FC-4417-B519-CAFC62E5BC39@bitgravity.com> <04C305AE5F184C6AAC2A67CE23184013@multiplay.co.uk> <3D893A9B-2CD9-40EB-B4A2-5DBCBB72C62E@bitgravity.com> <4E35D2E5.4020108@FreeBSD.org> <0E851F439C384186A1D44A347C19A7D7@multiplay.co.uk> <4E36A25F.7000000@FreeBSD.org> To: Martin Matuska X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@FreeBSD.org, Andriy Gapon Subject: Re: zfs process hang on pool access X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 18:01:27 -0000 On Aug 1, 2011, at 5:55 AM, Martin Matuska wrote: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c (revision >>> 224527) >>> +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c (working = copy) >>> @@ -488,7 +488,7 @@ >>> txg_delay(dsl_pool_t *dp, uint64_t txg, int ticks) >>> { >>> tx_state_t *tx =3D &dp->dp_tx; >>> - int timeout =3D ddi_get_lbolt() + ticks; >>> + clock_t timeout =3D ddi_get_lbolt() + ticks; >>=20 >> So you recon that one line will fix the 100+ days overflow David's >> talking about? > No, this bug causes that after 28,5 days of uptime this function won't > delay txg sync threads anymore (ddi_get_lbolt() will be always larger > than timeout).This may lead to a slowdown of writes. Thanks Martin. I see you committed to -head as well. However, a bit confused with my issue still. I've been able to = recreating it and I can't explain why LBOLT is still coming back = negative. I'm in 8.1-RELEASE in this case, with the patches that I = posted before for LBOLT and typedef of clock_t.=20 I added some debugging and am seeing LBOLT still return a negative = number, which then (timeout-LBOLT) because a large number of ticks to = wait. I put some debugging in txg_delay, without fixing the timeout's type: Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c = (revision 3343) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c = (working copy) @@ -427,6 +427,7 @@ { tx_state_t *tx =3D &dp->dp_tx; int timeout =3D LBOLT + ticks; + /* if ( timeout < 0 ) { printf ("txg_delay: timeout = negative timeout=3D%d, ticks=3D%d\n", timeout, ticks); } */ =20 /* don't delay if this txg could transition to = quiesing immediately */ if (tx->tx_open_txg > txg || @@ -439,10 +440,10 @@ return; } =20 - while (LBOLT < timeout && - tx->tx_syncing_txg < txg-1 && !txg_stalled(dp)) - (void) cv_timedwait(&tx->tx_quiesce_more_cv, = &tx->tx_sync_lock, - timeout - LBOLT); + while (LBOLT < timeout && tx->tx_syncing_txg < txg-1 && = !txg_stalled(dp)) { + printf ("txg_delay::cv_timeoutwait: = timeout negative timeout=3D%d, ticks=3D%d %lld \n", timeout, ticks, = LBOLT ); + (void) = cv_timedwait(&tx->tx_quiesce_more_cv, &tx->tx_sync_lock, timeout - = LBOLT); + } =20 mutex_exit(&tx->tx_sync_lock); } After two hours of doing 9 parallel file creates ... I got it deadlocked = ... well, probably just a long wait ... txg_delay::cv_timeoutwait: timeout negative timeout=3D-518109823, = ticks=3D1 -9182683359751551616 txg_delay::cv_timeoutwait: timeout negative timeout=3D-355729919, = ticks=3D1 -9182562881461551616 txg_delay::cv_timeoutwait: timeout negative timeout=3D1272384705, = ticks=3D1 -9182430354322551616 txg_delay::cv_timeoutwait: timeout negative timeout=3D1272384705, = ticks=3D1 -9182308872293551616 txg_delay::cv_timeoutwait: timeout negative timeout=3D1272384705, = ticks=3D1 -9182180363183551616 txg_delay::cv_timeoutwait: timeout negative timeout=3D1272384705, = ticks=3D1 -9182051853654551616 =09 Grabbed a core, and did some more poking : (kgdb) up #3 0xffffffff804d222b in _cv_timedwait (cvp=3D0xffffff0029524260,= =20 lock=3D0xffffff00295241d0, timo=3D1914894593) at /usr/src/sys/kern/kern_condvar.c:323 323 rval =3D sleepq_timedwait(cvp, 0); (kgdb) up #4 0xffffffff8106ef7e in txg_delay (dp=3D0xffffff0029524000, = txg=3D9264, ticks=3D1) at = /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/= txg.c:445 445 (void) = cv_timedwait(&tx->tx_quiesce_more_cv, &tx->tx_sync_lock, timeout - = LBOLT); (kgdb) info locals timeout =3D Variable "timeout" is not available. (kgdb)=20 As you can see, LBOLT is apparently negative - if I'm getting my printf = formatting correct - but regardless the timo value to cv_timedwait() is = timo=3D1914894593 ... which is trying to wait for : 1914894593 / 1000hz / 60s / 60m /24h =3D 22.16 hours Regardless of setting timeout's type correctly ... why is LBOLT still = negative ? It's not clear to me that fixing timeout's type will fix = this issue. However, I will do so, and re-run this same test.=20 My patches earlier show my changes to = sys/cddl/compat/opensolaris/sys/time.h but in summary : 37 #define NANOSEC 1000000000 39 typedef longlong_t hrtime_t; 41 #define LBOLT (gethrtime() * (NANOSEC/hz)) And gerhrtime() still remains unchanged from 8.1: 51 #ifdef _KERNEL 52 #define lbolt64 (int64_t)(LBOLT) 53=20 54 static __inline hrtime_t 55 gethrtime(void) { 56=20 57 struct timespec ts; 58 hrtime_t nsec; 59=20 60 #if 1 61 getnanouptime(&ts); 62 #else 63 nanouptime(&ts); 64 #endif 65 nsec =3D (hrtime_t)ts.tv_sec * NANOSEC + ts.tv_nsec; 66 return (nsec); 67 } 68=20 69 #define gethrestime_sec() (time_second) 70 #define gethrestime(ts) getnanotime(ts) --- David P. Discher dpd@bitgravity.com * AIM: bgDavidDPD BITGRAVITY * http://www.bitgravity.com From owner-freebsd-fs@FreeBSD.ORG Tue Aug 2 18:13:57 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32DE3106564A; Tue, 2 Aug 2011 18:13:57 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4772A8FC08; Tue, 2 Aug 2011 18:13:55 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA25322; Tue, 02 Aug 2011 21:13:52 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QoJTU-000Htv-AD; Tue, 02 Aug 2011 21:13:52 +0300 Message-ID: <4E383E5E.5050407@FreeBSD.org> Date: Tue, 02 Aug 2011 21:13:50 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: David P Discher References: <0D449EC916264947AB31AA17F870EA7A@multiplay.co.uk> <4E3013DF.10803@FreeBSD.org> <3D6CEB50BEDD4ACE96FD35C4D085618A@multiplay.co.uk> <4E301C55.7090105@FreeBSD.org> <5C84E7C8452E489C8CA738294F5EBB78@multiplay.co.uk> <4E301F10.6060708@FreeBSD.org> <63705B5AEEAD4BB88ADB9EF770AB6C76@multiplay.co.uk> <4E302204.2030009@FreeBSD.org> <6703F0BB-D4FC-4417-B519-CAFC62E5BC39@bitgravity.com> <04C305AE5F184C6AAC2A67CE23184013@multiplay.co.uk> <3D893A9B-2CD9-40EB-B4A2-5DBCBB72C62E@bitgravity.com> <4E35D2E5.4020108@FreeBSD.org> <0E851F439C384186A1D44A347C19A7D7@multiplay.co.uk> <4E36A25F.7000000@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, Martin Matuska Subject: Re: zfs process hang on pool access X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 18:13:57 -0000 on 02/08/2011 21:01 David P Discher said the following: > 41 #define LBOLT (gethrtime() * (NANOSEC/hz)) I think that you got this wrong in your local changes. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Aug 2 18:24:19 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17BDB1065673; Tue, 2 Aug 2011 18:24:19 +0000 (UTC) (envelope-from dpd@bitgravity.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id D23BA8FC1B; Tue, 2 Aug 2011 18:24:18 +0000 (UTC) Received: by pzk5 with SMTP id 5so154267pzk.17 for ; Tue, 02 Aug 2011 11:24:18 -0700 (PDT) Received: by 10.68.36.168 with SMTP id r8mr9686596pbj.321.1312309458172; Tue, 02 Aug 2011 11:24:18 -0700 (PDT) Received: from netops-199.sfo1.bitgravity.com (netops-199.sfo1.bitgravity.com [209.131.110.199]) by mx.google.com with ESMTPS id o6sm72967pbj.66.2011.08.02.11.24.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Aug 2011 11:24:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: David P Discher In-Reply-To: <4E383E5E.5050407@FreeBSD.org> Date: Tue, 2 Aug 2011 11:24:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D449EC916264947AB31AA17F870EA7A@multiplay.co.uk> <4E3013DF.10803@FreeBSD.org> <3D6CEB50BEDD4ACE96FD35C4D085618A@multiplay.co.uk> <4E301C55.7090105@FreeBSD.org> <5C84E7C8452E489C8CA738294F5EBB78@multiplay.co.uk> <4E301F10.6060708@FreeBSD.org> <63705B5AEEAD4BB88ADB9EF770AB6C76@multiplay.co.uk> <4E302204.2030009@FreeBSD.org> <6703F0BB-D4FC-4417-B519-CAFC62E5BC39@bitgravity.com> <04C305AE5F184C6AAC2A67CE23184013@multiplay.co.uk> <3D893A9B-2CD9-40EB-B4A2-5DBCBB72C62E@bitgravity.com> <4E35D2E5.4020108@FreeBSD.org> <0E851F439C384186A1D44A347C19A7D7@multiplay.co.uk> <4E36A25F.7000000@FreeBSD.org> <4E383E5E.5050407@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@FreeBSD.org, Martin Matuska Subject: Re: zfs process hang on pool access X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 18:24:19 -0000 On Aug 2, 2011, at 11:13 AM, Andriy Gapon wrote: > on 02/08/2011 21:01 David P Discher said the following: >> 41 #define LBOLT (gethrtime() * (NANOSEC/hz)) >=20 > I think that you got this wrong in your local changes. How is this different than what's in -head :=20 sys/cddl/compat/opensolaris/kern/opensolaris.c:65: = nsec_per_tick =3D NANOSEC / hz; sys/cddl/compat/opensolaris/sys/time.h:71: return (gethrtime() / = nsec_per_tick); The only difference is an explicit casting the return as int64_t ?=20 --- David P. Discher dpd@bitgravity.com * AIM: bgDavidDPD BITGRAVITY * http://www.bitgravity.com From owner-freebsd-fs@FreeBSD.ORG Tue Aug 2 19:04:08 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EEBC106568F; Tue, 2 Aug 2011 19:04:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A816F8FC1C; Tue, 2 Aug 2011 19:04:07 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA26030; Tue, 02 Aug 2011 22:04:03 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QoKG3-000Hwc-BR; Tue, 02 Aug 2011 22:04:03 +0300 Message-ID: <4E384A22.5000402@FreeBSD.org> Date: Tue, 02 Aug 2011 22:04:02 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: David P Discher References: <0D449EC916264947AB31AA17F870EA7A@multiplay.co.uk> <4E3013DF.10803@FreeBSD.org> <3D6CEB50BEDD4ACE96FD35C4D085618A@multiplay.co.uk> <4E301C55.7090105@FreeBSD.org> <5C84E7C8452E489C8CA738294F5EBB78@multiplay.co.uk> <4E301F10.6060708@FreeBSD.org> <63705B5AEEAD4BB88ADB9EF770AB6C76@multiplay.co.uk> <4E302204.2030009@FreeBSD.org> <6703F0BB-D4FC-4417-B519-CAFC62E5BC39@bitgravity.com> <04C305AE5F184C6AAC2A67CE23184013@multiplay.co.uk> <3D893A9B-2CD9-40EB-B4A2-5DBCBB72C62E@bitgravity.com> <4E35D2E5.4020108@FreeBSD.org> <0E851F439C384186A1D44A347C19A7D7@multiplay.co.uk> <4E36A25F.7000000@FreeBSD.org> <4E383E5E.5050407@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, Martin Matuska Subject: Re: zfs process hang on pool access X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 19:04:09 -0000 on 02/08/2011 21:24 David P Discher said the following: > > On Aug 2, 2011, at 11:13 AM, Andriy Gapon wrote: > >> on 02/08/2011 21:01 David P Discher said the following: >>> 41 #define LBOLT (gethrtime() * (NANOSEC/hz)) >> >> I think that you got this wrong in your local changes. > > > > How is this different than what's in -head : > > sys/cddl/compat/opensolaris/kern/opensolaris.c:65: nsec_per_tick = NANOSEC / hz; > > sys/cddl/compat/opensolaris/sys/time.h:71: return (gethrtime() / nsec_per_tick); > > > The only difference is an explicit casting the return as int64_t ? No. You need to look at the maths ;-) Note the absence of '*' symbols in the quote from head. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Aug 2 20:44:39 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE3291065674; Tue, 2 Aug 2011 20:44:39 +0000 (UTC) (envelope-from dpd@bitgravity.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9CA5C8FC27; Tue, 2 Aug 2011 20:44:39 +0000 (UTC) Received: by pzk5 with SMTP id 5so576234pzk.17 for ; Tue, 02 Aug 2011 13:44:39 -0700 (PDT) Received: by 10.68.39.133 with SMTP id p5mr3463213pbk.294.1312317878821; Tue, 02 Aug 2011 13:44:38 -0700 (PDT) Received: from netops-199.sfo1.bitgravity.com (netops-199.sfo1.bitgravity.com [209.131.110.199]) by mx.google.com with ESMTPS id z6sm189722pbc.62.2011.08.02.13.44.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Aug 2011 13:44:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: David P Discher In-Reply-To: <4E384A22.5000402@FreeBSD.org> Date: Tue, 2 Aug 2011 13:44:36 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <0D449EC916264947AB31AA17F870EA7A@multiplay.co.uk> <4E3013DF.10803@FreeBSD.org> <3D6CEB50BEDD4ACE96FD35C4D085618A@multiplay.co.uk> <4E301C55.7090105@FreeBSD.org> <5C84E7C8452E489C8CA738294F5EBB78@multiplay.co.uk> <4E301F10.6060708@FreeBSD.org> <63705B5AEEAD4BB88ADB9EF770AB6C76@multiplay.co.uk> <4E302204.2030009@FreeBSD.org> <6703F0BB-D4FC-4417-B519-CAFC62E5BC39@bitgravity.com> <04C305AE5F184C6AAC2A67CE23184013@multiplay.co.uk> <3D893A9B-2CD9-40EB-B4A2-5DBCBB72C62E@bitgravity.com> <4E35D2E5.4020108@FreeBSD.org> <0E851F439C384186A1D44A347C19A7D7@multiplay.co.uk> <4E36A25F.7000000@FreeBSD.org> <4E383E5E.5050407@FreeBSD.org> <4E384A22.5000402@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@FreeBSD.org, Martin Matuska Subject: Re: zfs process hang on pool access X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:44:39 -0000 DOH! Thanks. sigh. --- David P. Discher dpd@bitgravity.com * AIM: bgDavidDPD BITGRAVITY * http://www.bitgravity.com On Aug 2, 2011, at 12:04 PM, Andriy Gapon wrote: > No. You need to look at the maths ;-) > Note the absence of '*' symbols in the quote from head. From owner-freebsd-fs@FreeBSD.ORG Wed Aug 3 03:30:12 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51EDC106566B for ; Wed, 3 Aug 2011 03:30:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 116538FC13 for ; Wed, 3 Aug 2011 03:30:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p733UB7e091726 for ; Wed, 3 Aug 2011 03:30:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p733UBaW091723; Wed, 3 Aug 2011 03:30:11 GMT (envelope-from gnats) Resent-Date: Wed, 3 Aug 2011 03:30:11 GMT Resent-Message-Id: <201108030330.p733UBaW091723@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-fs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Test Rat Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CE341065670 for ; Wed, 3 Aug 2011 03:27:58 +0000 (UTC) (envelope-from ttsestt@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA6D8FC12 for ; Wed, 3 Aug 2011 03:27:57 +0000 (UTC) Received: by fxe4 with SMTP id 4so636386fxe.13 for ; Tue, 02 Aug 2011 20:27:56 -0700 (PDT) Received: by 10.223.24.92 with SMTP id u28mr9133265fab.148.1312342076865; Tue, 02 Aug 2011 20:27:56 -0700 (PDT) Received: from localhost (tor3.anonymizer.ccc.de [80.237.226.73]) by mx.google.com with ESMTPS id d6sm237669fak.10.2011.08.02.20.27.54 (version=SSLv3 cipher=OTHER); Tue, 02 Aug 2011 20:27:56 -0700 (PDT) Message-Id: <868vrbjhse.fsf@gmail.com> Date: Wed, 03 Aug 2011 07:27:45 +0400 From: Test Rat To: FreeBSD-gnats-submit@FreeBSD.org Cc: Subject: misc/159402: [zfs][loader] symlinks cause I/O errors X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 03:30:12 -0000 >Number: 159402 >Category: misc >Synopsis: [zfs][loader] symlinks cause I/O errors >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-fs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Aug 03 03:30:11 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Anonymous >Release: FreeBSD 9.0-CURRENT amd64 >Organization: >Environment: >Description: Unlike loader (on UFS) that follows symlinks zfsloader chokes on them. >How-To-Repeat: $ cd /boot $ mv kernel foo $ ln -s foo kernel $ qemu-system-x86_64 -nographic ... Consoles: serial port BIOS drive C: is disk0 BIOS 637kB/523252kB available memory FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.1 (root@build-amd64-fbsd.allbsd.org, Thu Jul 21 04:11:07 UTC 2011) Loading /boot/defaults/loader.conf ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable Unable to load a kernel! | can't load 'kernel' >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-fs@FreeBSD.ORG Wed Aug 3 11:38:42 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DECEE106566B for ; Wed, 3 Aug 2011 11:38:42 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop02.sare.net (proxypop02.sare.net [194.30.18.43]) by mx1.freebsd.org (Postfix) with ESMTP id A163C8FC12 for ; Wed, 3 Aug 2011 11:38:42 +0000 (UTC) Received: from [172.16.1.55] (izaro.sarenet.es [192.148.167.11]) by proxypop02.sare.net (Postfix) with ESMTPSA id 29BF7109F0D9 for ; Wed, 3 Aug 2011 13:22:19 +0200 (CEST) From: Borja Marcos Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Aug 2011 13:22:23 +0200 Message-Id: <19D8728E-6C92-4882-BDEB-8DDC4918B997@sarenet.es> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: ZFS v28 issues with "zfs" command X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 11:38:42 -0000 Hello, I've been doing tests with FreeBSD 8-STABLE, cvsupped yesterday.=20 First, I haven't been able to reproduce the deadlock I observed several = times when receiving a snapshot on a dataset on which there was some = reading activity. So this bug seems to be solved. However, I've seen something worrysome.=20 I'm using a small, simple replication program. At given intervals, right = now i'm using 20 second intervals, it sends an incremental snapshot to a = secondary machine. The algorithm is this: (time to replicate a new snapshot) ssh destination zfs list -t snapshot... zfs list -t snapshot determine most recent snapshot in common zfs snapshot pool/dataset@thenew (name format is = pool/dataset@YYYYMMDDHHMMSS) zfs send -i most_recent_snapshot_in_common new_snapshot > = /var/tmp/temp_filename scp /var/tmp/temp_filename destination:/var/tmp ssh destination zfs receive -d pool < /var/tmp/femp_filename ssh destination zfs destroy pool/most_recent_snapshot_in_common The program works, it's pretty simple.=20 However, I've found a problem. While it was working, I ran "zfs list -t = snapshot" several times on the destination machine. I can't recall if it = was during the zfs receive or the zfs destroy command, but after that = something went wrong. I noticed that destroying a snapshot got an error = message, despite the fact that the snapshots were really destroyed. Inspecting the pool with zdb -d (found it doing some Google searches) I = noticed that I had developed a "hidden clone" problem. And I saw this = snapshot which, aparently, came from nowhere: rpool/tachan@newsrc-23608-1 1.33K - 786M - Seems that there's some contention issue affecting the zfs command. In = my case, it was triggered by a "zfs list -t snapshot" command during = either a "zfs receive -d -F" or a "zfs destroy". I'm wondering how to capture useful data regarding this... =20 Borja. From owner-freebsd-fs@FreeBSD.ORG Thu Aug 4 11:00:26 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95F29106564A for ; Thu, 4 Aug 2011 11:00:26 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6F34D8FC0C for ; Thu, 4 Aug 2011 11:00:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p74B0Qq7011678 for ; Thu, 4 Aug 2011 11:00:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p74B0Qur011677; Thu, 4 Aug 2011 11:00:26 GMT (envelope-from gnats) Date: Thu, 4 Aug 2011 11:00:26 GMT Message-Id: <201108041100.p74B0Qur011677@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Borja Marcos Cc: Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Borja Marcos List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 11:00:26 -0000 The following reply was made to PR kern/157728; it has been noted by GNATS. From: Borja Marcos To: bug-followup@FreeBSD.org, mm@FreeBSD.org Cc: Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones Date: Thu, 4 Aug 2011 12:39:58 +0200 I have a clue. I've tried a partial fix and so far seems to work. Now I = have a loop doing zfs sends of a dataset with a make buildworld = running, each 30 seconds, and receiving them onto a different pool, on = which I have a while ( 1 ) ; zfs list ; end loop running. So far I haven't had issues. The only side effect is that temporary = datasets can appear in the zfs list output.=20 Read below for the explanation. After reading Martin's analysis, seemed quite clear to me that the = scenario was due to the necessity of getting a consistent snapshot of = the state of a complex data structure. In this case, I imagined that the = "list" service would traverse the data structures holding the datasets = descriptions, and that it would place temporary locks on the elements in = order to prevent them from being altered while the structure is being = traversed. So, a generic "list" service in a fine-grained locking environment and = rendering a consistent response would be something like that: - traverse data structure, building a list. (each time we get an element, a temporary lock is placed on it) - get next element, etc. - With the complete and consistent list ready, prepare the response. - Once the response has been built, traverse the grabbed results and = release the locks. So, where's the problem? In the special treatment of the "hidden" = datasets. Looking at = /usr/src/sys/cddl/contrib/opensolaris/common/fs/zfs/zfs_ioctl.c, at the = function zfs_ioc_dataset_list_next(zfs_cmd_t *zc) I see something resembling this idea: while (error =3D=3D 0 && dataset_name_hidden(zc->zc_name) && !(zc->zc_iflags & FKIOCTL)); dmu_objset_rele(os, FTAG); So, wondering if the problem is this, giving a special treatment to the = hidden dataset, I've edited the dataset_name_hidden() function so that = it ignores the "%" datasets. boolean_t dataset_name_hidden(const char *name) { /* * Skip over datasets that are not visible in this zone, * internal datasets (which have a $ in their name), and * temporary datasets (which have a % in their name). */ if (strchr(name, '$') !=3D NULL) return (B_TRUE); /* if (strchr(name, '%') !=3D NULL) return (B_TRUE); */ if (!INGLOBALZONE(curthread) && !zone_dataset_visible(name, = NULL)) return (B_TRUE); return (B_FALSE); } =20 I was expecting just a side-effect: a "zfs list" would list the = "%"datasets. Done this, I've compiled the kernel, started the test again, and, voila! = it works. Of course, now I see the "%" datasets while the zfs receive is running, pruebazfs3# zfs list -t all NAME USED AVAIL REFER MOUNTPOINT rpool 1.22G 6.61G 41.3K /rpool rpool/newsrc 1.22G 6.61G 565M /rpool/newsrc rpool/newsrc@anteshidden 149M - 973M - rpool/newsrc@parcheteoria1 1.09M - 973M - rpool/newsrc@20110804_113700 0 - 565M - rpool/newsrc/%20110804_113730 1.31M 6.61G 566M = /rpool/newsrc/%20110804_113730 but after zfs receive finishes they are correctly cleaned up NAME USED AVAIL REFER MOUNTPOINT rpool 1.22G 6.61G 41.3K /rpool rpool/newsrc 1.22G 6.61G 566M /rpool/newsrc rpool/newsrc@anteshidden 149M - 973M - rpool/newsrc@parcheteoria1 1.09M - 973M - rpool/newsrc@20110804_113730 0 - 566M - So: Seems to me that these datasets are a sort of afterthought. The = ioctl "list" service should not discard them when building the dataset = list. Instead it should not "print" them, so to speak. I'm sure this temporary fix can be refined, and I'm wondering if a = similar issue is lurking somewhere else.... Borja. From owner-freebsd-fs@FreeBSD.ORG Thu Aug 4 12:40:12 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C1071065672 for ; Thu, 4 Aug 2011 12:40:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1ACE78FC1A for ; Thu, 4 Aug 2011 12:40:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p74CeBwO008142 for ; Thu, 4 Aug 2011 12:40:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p74CeBxw008141; Thu, 4 Aug 2011 12:40:11 GMT (envelope-from gnats) Date: Thu, 4 Aug 2011 12:40:11 GMT Message-Id: <201108041240.p74CeBxw008141@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Matuska Cc: Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Matuska List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 12:40:12 -0000 The following reply was made to PR kern/157728; it has been noted by GNATS. From: Martin Matuska To: Borja Marcos Cc: bug-followup@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones Date: Thu, 04 Aug 2011 14:33:45 +0200 This is a multi-part message in MIME format. --------------090908080609040403050308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit That is not a solution, we want hidden datasets :) A workaround patch is attached that does not prefetch hidden datasets in zfs (btw. why should we do that at all). It doesn't cure the source of the problem but the symptoms - to reproduce the problem you have to run zfs list or get directly on the invisible temporary clone now. Please test. Dňa 04.08.2011 12:39, Borja Marcos wrote / napísal(a): > I have a clue. I've tried a partial fix and so far seems to work. Now I have a loop doing zfs sends of a dataset with a make buildworld running, each 30 seconds, and receiving them onto a different pool, on which I have a while ( 1 ) ; zfs list ; end loop running. > > So far I haven't had issues. The only side effect is that temporary datasets can appear in the zfs list output. > > Read below for the explanation. > > After reading Martin's analysis, seemed quite clear to me that the scenario was due to the necessity of getting a consistent snapshot of the state of a complex data structure. In this case, I imagined that the "list" service would traverse the data structures holding the datasets descriptions, and that it would place temporary locks on the elements in order to prevent them from being altered while the structure is being traversed. > > So, a generic "list" service in a fine-grained locking environment and rendering a consistent response would be something like that: > > - traverse data structure, building a list. > (each time we get an element, a temporary lock is placed on it) > - get next element, etc. > > - With the complete and consistent list ready, prepare the response. > > - Once the response has been built, traverse the grabbed results and release the locks. > > > So, where's the problem? In the special treatment of the "hidden" datasets. > > Looking at /usr/src/sys/cddl/contrib/opensolaris/common/fs/zfs/zfs_ioctl.c, at the function zfs_ioc_dataset_list_next(zfs_cmd_t *zc) > > I see something resembling this idea: > > while (error == 0 && dataset_name_hidden(zc->zc_name) && > !(zc->zc_iflags & FKIOCTL)); > dmu_objset_rele(os, FTAG); > > So, wondering if the problem is this, giving a special treatment to the hidden dataset, I've edited the dataset_name_hidden() function so that it ignores the "%" datasets. > > boolean_t > dataset_name_hidden(const char *name) > { > /* > * Skip over datasets that are not visible in this zone, > * internal datasets (which have a $ in their name), and > * temporary datasets (which have a % in their name). > */ > if (strchr(name, '$') != NULL) > return (B_TRUE); > /* if (strchr(name, '%') != NULL) > return (B_TRUE); */ > if (!INGLOBALZONE(curthread) && !zone_dataset_visible(name, NULL)) > return (B_TRUE); > return (B_FALSE); > } > > > I was expecting just a side-effect: a "zfs list" would list the "%"datasets. > > Done this, I've compiled the kernel, started the test again, and, voila! it works. > > Of course, now I see the "%" datasets while the zfs receive is running, > > pruebazfs3# zfs list -t all > NAME USED AVAIL REFER MOUNTPOINT > rpool 1.22G 6.61G 41.3K /rpool > rpool/newsrc 1.22G 6.61G 565M /rpool/newsrc > rpool/newsrc@anteshidden 149M - 973M - > rpool/newsrc@parcheteoria1 1.09M - 973M - > rpool/newsrc@20110804_113700 0 - 565M - > rpool/newsrc/%20110804_113730 1.31M 6.61G 566M /rpool/newsrc/%20110804_113730 > > > but after zfs receive finishes they are correctly cleaned up > > NAME USED AVAIL REFER MOUNTPOINT > rpool 1.22G 6.61G 41.3K /rpool > rpool/newsrc 1.22G 6.61G 566M /rpool/newsrc > rpool/newsrc@anteshidden 149M - 973M - > rpool/newsrc@parcheteoria1 1.09M - 973M - > rpool/newsrc@20110804_113730 0 - 566M - > > > So: Seems to me that these datasets are a sort of afterthought. The ioctl "list" service should not discard them when building the dataset list. Instead it should not "print" them, so to speak. > > I'm sure this temporary fix can be refined, and I'm wondering if a similar issue is lurking somewhere else.... -- Martin Matuska FreeBSD committer http://blog.vx.sk --------------090908080609040403050308 Content-Type: text/x-patch; name="zfs_ioctl.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="zfs_ioctl.c.patch" Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c (revision 224648) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c (working copy) @@ -1963,8 +1963,13 @@ zfs_ioc_dataset_list_next() uint64_t cookie = 0; int len = sizeof (zc->zc_name) - (p - zc->zc_name); - while (dmu_dir_list_next(os, len, p, NULL, &cookie) == 0) - (void) dmu_objset_prefetch(zc->zc_name, NULL); + while (dmu_dir_list_next(os, len, p, NULL, + &cookie) == 0) { + if (dataset_name_hidden(zc->zc_name) == B_FALSE) { + (void) dmu_objset_prefetch(zc->zc_name, + NULL); + } + } } do { --------------090908080609040403050308-- From owner-freebsd-fs@FreeBSD.ORG Thu Aug 4 13:50:12 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7BDF106564A for ; Thu, 4 Aug 2011 13:50:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C71568FC08 for ; Thu, 4 Aug 2011 13:50:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p74DoCFD071907 for ; Thu, 4 Aug 2011 13:50:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p74DoCTf071905; Thu, 4 Aug 2011 13:50:12 GMT (envelope-from gnats) Date: Thu, 4 Aug 2011 13:50:12 GMT Message-Id: <201108041350.p74DoCTf071905@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Borja Marcos Cc: Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Borja Marcos List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 13:50:12 -0000 The following reply was made to PR kern/157728; it has been noted by GNATS. From: Borja Marcos To: Martin Matuska Cc: bug-followup@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones Date: Thu, 4 Aug 2011 15:40:03 +0200 On Aug 4, 2011, at 2:33 PM, Martin Matuska wrote: > That is not a solution, we want hidden datasets :) >=20 > A workaround patch is attached that does not prefetch hidden datasets = in > zfs (btw. why should we do that at all). > It doesn't cure the source of the problem but the symptoms - to > reproduce the problem you have to run zfs list or get directly on the > invisible temporary clone now. Well, still there might be a subtle problem. I mean, and sorry if it's a somewhat trivial question, but it-s the = first time I actually read some ZFS internals code ;) Does that prefetch *imply* a temporary lock being placed? I mean, in = such a case usually you need an atomic fetch-and-lock operation. I'm wondering if not prefetching them could be a problem, and = instead it would be a better solution to keep prefetching them but avoiding to display them, so that any side effects are preserved. = Otherwise that might have some ugly interaction. Of course my patch isn't a solution, I wanted a quick experiment to find = out if the special treatment of the hidden datasets was the issue. But, = really, the decision not to show a hidden dataset shouldn't be made at a = such low level because of these interactions. The problem is, the patch = might work but introduce harder to reproduce issues? Maybe Pawel can help us, I guess he's much more familiar than us with = the guts of ZFS ;) Borja. From owner-freebsd-fs@FreeBSD.ORG Thu Aug 4 13:50:14 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F04771065670 for ; Thu, 4 Aug 2011 13:50:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E08328FC0C for ; Thu, 4 Aug 2011 13:50:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p74DoE5W071915 for ; Thu, 4 Aug 2011 13:50:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p74DoEPh071914; Thu, 4 Aug 2011 13:50:14 GMT (envelope-from gnats) Date: Thu, 4 Aug 2011 13:50:14 GMT Message-Id: <201108041350.p74DoEPh071914@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Borja Marcos Cc: Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Borja Marcos List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 13:50:15 -0000 The following reply was made to PR kern/157728; it has been noted by GNATS. From: Borja Marcos To: Martin Matuska Cc: bug-followup@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones Date: Thu, 4 Aug 2011 15:40:47 +0200 On Aug 4, 2011, at 2:33 PM, Martin Matuska wrote: > That is not a solution, we want hidden datasets :) >=20 > A workaround patch is attached that does not prefetch hidden datasets = in > zfs (btw. why should we do that at all). > It doesn't cure the source of the problem but the symptoms - to > reproduce the problem you have to run zfs list or get directly on the > invisible temporary clone now. And, besides, shouldn't this be coordinated with the rest of the ZFS = community?=20 Borja. From owner-freebsd-fs@FreeBSD.ORG Thu Aug 4 13:55:55 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CD881065670 for ; Thu, 4 Aug 2011 13:55:55 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id 2E21F8FC0A for ; Thu, 4 Aug 2011 13:55:55 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id DA8B016BCFB; Thu, 4 Aug 2011 15:55:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HEBzL-B0jwOh; Thu, 4 Aug 2011 15:55:50 +0200 (CEST) Received: from [10.0.3.3] (188-167-66-148.dynamic.chello.sk [188.167.66.148]) by mail.vx.sk (Postfix) with ESMTPSA id 91C5916BCEB; Thu, 4 Aug 2011 15:55:50 +0200 (CEST) Message-ID: <4E3AA4E5.2030900@FreeBSD.org> Date: Thu, 04 Aug 2011 15:55:49 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: Borja Marcos References: <201108041350.p74DoEPh071914@freefall.freebsd.org> In-Reply-To: <201108041350.p74DoEPh071914@freefall.freebsd.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 13:55:55 -0000 ZFS development at Oracle has gone private. Working ZFS is currently available at Illumos (Openindiana), FreeBSD and zfsonlinux (LLNL, Behlendorf). I file bugs related to common ZFS code to the Illumos issues list and am also in touch with zfsonlinux (https://github.com/zfsonlinux) https://www.illumos.org/issues/1043 https://www.illumos.org/issues/1313 The bug is probably not related to common ZFS code, because I am unable to reproduce the issue on Solaris, Openindiana and Linux (zfsonlinux kernel module). Discussions of this type are more for the mailing lists and less for the PR system. Please stay related to the bug in the PR and continue the discussion here (freebsd-fs@). Dňa 04.08.2011 15:50, Borja Marcos wrote / napísal(a): > The following reply was made to PR kern/157728; it has been noted by GNATS. > > From: Borja Marcos > To: Martin Matuska > Cc: bug-followup@FreeBSD.org, > Pawel Jakub Dawidek > Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones > Date: Thu, 4 Aug 2011 15:40:47 +0200 > > On Aug 4, 2011, at 2:33 PM, Martin Matuska wrote: > > > That is not a solution, we want hidden datasets :) > >=20 > > A workaround patch is attached that does not prefetch hidden datasets = > in > > zfs (btw. why should we do that at all). > > It doesn't cure the source of the problem but the symptoms - to > > reproduce the problem you have to run zfs list or get directly on the > > invisible temporary clone now. > > And, besides, shouldn't this be coordinated with the rest of the ZFS > community? -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Thu Aug 4 14:20:12 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDF17106564A for ; Thu, 4 Aug 2011 14:20:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 946408FC12 for ; Thu, 4 Aug 2011 14:20:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p74EKCCA098804 for ; Thu, 4 Aug 2011 14:20:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p74EKCbY098803; Thu, 4 Aug 2011 14:20:12 GMT (envelope-from gnats) Date: Thu, 4 Aug 2011 14:20:12 GMT Message-Id: <201108041420.p74EKCbY098803@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Matuska Cc: Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Matuska List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 14:20:12 -0000 The following reply was made to PR kern/157728; it has been noted by GNATS. From: Martin Matuska To: Borja Marcos Cc: bug-followup@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones Date: Thu, 04 Aug 2011 16:18:48 +0200 What is for sure that there is an additional lock placed on the clone that is not removed, or at least not immediately. The fact that you are able to delete the clone afterwards means that the lock has been released - it might be a race between tasks. In my opinion the lock is placed on any access on the temporary clone (no mater if prefetch or fetch). But I still think we don't have to prefetch data we are not processing. I don't think that there will be any ugly interaction in this case. The idea of the prefetch code is to speed up access to the data structure by caching it into memory. So what we don't prefetch (is not cached) will be read the normal way (and not from cache). If you follow its history, you can see it well: Prefetch for zfs list was introduced in OpenSolaris changeset 8415 and didn't change very much since that point: http://hg.openindiana.org/illumos-gate/rev/d5525cd1cbc2 If you remove that code, it will still work the way it should, but slower :) I still see no problem in not-prefetching hidden datasets. Dňa 04.08.2011 15:40, Borja Marcos wrote / napísal(a): > On Aug 4, 2011, at 2:33 PM, Martin Matuska wrote: > > > Well, still there might be a subtle problem. > > I mean, and sorry if it's a somewhat trivial question, but it-s the first time I actually read some ZFS internals code ;) > > Does that prefetch *imply* a temporary lock being placed? I mean, in such a case usually you need an atomic fetch-and-lock > operation. I'm wondering if not prefetching them could be a problem, and instead it would be a better solution to keep prefetching them > but avoiding to display them, so that any side effects are preserved. Otherwise that might have some ugly interaction. > > Of course my patch isn't a solution, I wanted a quick experiment to find out if the special treatment of the hidden datasets was the issue. But, really, the decision not to show a hidden dataset shouldn't be made at a such low level because of these interactions. The problem is, the patch might work but introduce harder to reproduce issues? > > Maybe Pawel can help us, I guess he's much more familiar than us with the guts of ZFS ;) -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Thu Aug 4 15:40:10 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B7CA1065670 for ; Thu, 4 Aug 2011 15:40:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 860F38FC13 for ; Thu, 4 Aug 2011 15:40:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p74FeA9b072230 for ; Thu, 4 Aug 2011 15:40:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p74FeALk072229; Thu, 4 Aug 2011 15:40:10 GMT (envelope-from gnats) Date: Thu, 4 Aug 2011 15:40:10 GMT Message-Id: <201108041540.p74FeALk072229@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Borja Marcos Cc: Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Borja Marcos List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:40:10 -0000 The following reply was made to PR kern/157728; it has been noted by GNATS. From: Borja Marcos To: Martin Matuska Cc: bug-followup@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones Date: Thu, 4 Aug 2011 17:37:26 +0200 On Aug 4, 2011, at 4:18 PM, Martin Matuska wrote: > But I still think we don't have to prefetch data we are not = processing. >=20 > I don't think that there will be any ugly interaction in this case. > The idea of the prefetch code is to speed up access to the data > structure by caching it into memory. > So what we don't prefetch (is not cached) will be read the normal way > (and not from cache). >=20 > If you follow its history, you can see it well: >=20 > Prefetch for zfs list was introduced in OpenSolaris changeset 8415 and > didn't change very much since that point: > http://hg.openindiana.org/illumos-gate/rev/d5525cd1cbc2 >=20 > If you remove that code, it will still work the way it should, but = slower :) > I still see no problem in not-prefetching hidden datasets. Understood :) Thank you very much. As I said, I'm not that familiar with = the internals. I'm going to try the patch and will let you know the outcome. I guess = it will effectively fix it. Best regards, Borja. From owner-freebsd-fs@FreeBSD.ORG Thu Aug 4 23:27:16 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BF78106567F for ; Thu, 4 Aug 2011 23:27:16 +0000 (UTC) (envelope-from prvs=11971cf4bd=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7714F8FC0A for ; Thu, 4 Aug 2011 23:27:03 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Fri, 05 Aug 2011 00:10:15 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 05 Aug 2011 00:10:15 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014471718.msg for ; Fri, 05 Aug 2011 00:10:14 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11971cf4bd=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@FreeBSD.ORG Message-ID: <2D117F9F212A4CCBA6B7F51E8705BDB7@multiplay.co.uk> From: "Steven Hartland" To: "Steven Hartland" , "Jeremy Chadwick" References: <13BEC27B17D24D0CBF2E6A98FD3227F3@multiplay.co.uk><20110728012437.GA23430@icarus.home.lan><20110728103234.GA33275@icarus.home.lan><20110728145917.GA37805@icarus.home.lan> <2A07CD8AE6AE49A5BAED59A7E547D1F9@multiplay.co.uk> Date: Fri, 5 Aug 2011 00:10:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Questions about erasing an ssd to restore performance under FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:27:16 -0000 ----- Original Message ----- From: "Steven Hartland" >> Understood. I'm off work this week so I'll see if I can dedicate some >> time to it. Too many non-work projects I'm juggling right now, argh. >> >> I'll have to start with camcontrol since the test system I have uses >> ada(4) and not classic ata(4). I'm not even sure what I'm really in for >> given that I've never looked at camcontrol's code before. >> >> If I "brick" my SSD I'll send you a bill, Steven. Kidding. :-) We seem to be having this issue on more disks now so I thought I'd have a bash at it to see how far I could get. To my suprise I think I've pretty much got it all the ata security options added to camcontrol. The only outstanding issue seems to be cam / ata appears to have an overflow bug which limits timeouts to 2147 seconds or less which would likely cause issues for rotary disks. I've posted about this in a seperate thread "cam / ata timeout limited to 2147 due to overflow bug?" In the mean time would you be interested in reviewing the code Jeremy? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Fri Aug 5 01:30:36 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C8661065670; Fri, 5 Aug 2011 01:30:36 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D7E028FC0A; Fri, 5 Aug 2011 01:30:35 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p751UZk4016521; Fri, 5 Aug 2011 01:30:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p751UZKK016507; Fri, 5 Aug 2011 01:30:35 GMT (envelope-from linimon) Date: Fri, 5 Aug 2011 01:30:35 GMT Message-Id: <201108050130.p751UZKK016507@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/159351: [nfs] [patch] - divide by zero in mountnfs() X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 01:30:36 -0000 Old Synopsis: [patch] - divide by zero in mountnfs() New Synopsis: [nfs] [patch] - divide by zero in mountnfs() Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 5 01:30:23 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=159351 From owner-freebsd-fs@FreeBSD.ORG Fri Aug 5 01:33:29 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AE521065670; Fri, 5 Aug 2011 01:33:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 027AC8FC1B; Fri, 5 Aug 2011 01:33:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p751XSUV024136; Fri, 5 Aug 2011 01:33:28 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p751XSkI024132; Fri, 5 Aug 2011 01:33:28 GMT (envelope-from linimon) Date: Fri, 5 Aug 2011 01:33:28 GMT Message-Id: <201108050133.p751XSkI024132@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/159356: [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-specific X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 01:33:29 -0000 Old Synopsis: ZFS NAME_ERR_DISKLIKE check is Solaris-specific New Synopsis: [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-specific Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 5 01:33:06 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=159356 From owner-freebsd-fs@FreeBSD.ORG Fri Aug 5 01:33:56 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C7B41065673; Fri, 5 Aug 2011 01:33:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 03D1A8FC1D; Fri, 5 Aug 2011 01:33:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p751Xt5j024232; Fri, 5 Aug 2011 01:33:55 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p751XtdT024228; Fri, 5 Aug 2011 01:33:55 GMT (envelope-from linimon) Date: Fri, 5 Aug 2011 01:33:55 GMT Message-Id: <201108050133.p751XtdT024228@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/159357: [zfs] ZFS MAXNAMELEN macro has confusing name (off-by-one) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 01:33:56 -0000 Old Synopsis: ZFS MAXNAMELEN macro has confusing name (off-by-one) New Synopsis: [zfs] ZFS MAXNAMELEN macro has confusing name (off-by-one) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 5 01:33:39 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=159357 From owner-freebsd-fs@FreeBSD.ORG Fri Aug 5 02:45:11 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86C071065670; Fri, 5 Aug 2011 02:45:11 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D01F98FC13; Fri, 5 Aug 2011 02:45:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p752jAuq087764; Fri, 5 Aug 2011 02:45:10 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p752jAbx087760; Fri, 5 Aug 2011 02:45:10 GMT (envelope-from linimon) Date: Fri, 5 Aug 2011 02:45:10 GMT Message-Id: <201108050245.p752jAbx087760@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/159418: [tmpfs] [panic] tmpfs kernel panic: recursing on non recursive lockmgr tmpfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 02:45:11 -0000 Old Synopsis: tmpfs kernel panic: recursing on non recursive lockmgr tmpfs New Synopsis: [tmpfs] [panic] tmpfs kernel panic: recursing on non recursive lockmgr tmpfs Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 5 02:44:45 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=159418 From owner-freebsd-fs@FreeBSD.ORG Fri Aug 5 03:30:18 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0C96106566C for ; Fri, 5 Aug 2011 03:30:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id D231A8FC13 for ; Fri, 5 Aug 2011 03:30:18 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta10.emeryville.ca.mail.comcast.net with comcast id GTQz1h0041smiN4AATWEAA; Fri, 05 Aug 2011 03:30:14 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id GTWb1h01p1t3BNj8gTWkar; Fri, 05 Aug 2011 03:30:47 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C4537102C19; Thu, 4 Aug 2011 20:30:01 -0700 (PDT) Date: Thu, 4 Aug 2011 20:30:01 -0700 From: Jeremy Chadwick To: Steven Hartland Message-ID: <20110805033001.GA47366@icarus.home.lan> References: <13BEC27B17D24D0CBF2E6A98FD3227F3@multiplay.co.uk> <20110728012437.GA23430@icarus.home.lan> <20110728103234.GA33275@icarus.home.lan> <20110728145917.GA37805@icarus.home.lan> <2A07CD8AE6AE49A5BAED59A7E547D1F9@multiplay.co.uk> <2D117F9F212A4CCBA6B7F51E8705BDB7@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D117F9F212A4CCBA6B7F51E8705BDB7@multiplay.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Questions about erasing an ssd to restore performance under FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 03:30:19 -0000 On Fri, Aug 05, 2011 at 12:10:40AM +0100, Steven Hartland wrote: > ----- Original Message ----- From: "Steven Hartland" > >>Understood. I'm off work this week so I'll see if I can dedicate some > >>time to it. Too many non-work projects I'm juggling right now, argh. > >> > >>I'll have to start with camcontrol since the test system I have uses > >>ada(4) and not classic ata(4). I'm not even sure what I'm really in for > >>given that I've never looked at camcontrol's code before. > >> > >>If I "brick" my SSD I'll send you a bill, Steven. Kidding. :-) > > We seem to be having this issue on more disks now so I thought I'd > have a bash at it to see how far I could get. To my suprise I think > I've pretty much got it all the ata security options added to camcontrol. > > The only outstanding issue seems to be cam / ata appears to have an > overflow bug which limits timeouts to 2147 seconds or less which would > likely cause issues for rotary disks. > > I've posted about this in a seperate thread > "cam / ata timeout limited to 2147 due to overflow bug?" > > In the mean time would you be interested in reviewing the code Jeremy? I can try. I started working on it myself last weekend and ended up experiencing some anomalies that required me to mail mav@. My request CDBs through CAM were being rejected with ABRT (which can happen per ATA specification when certain criteria aren't met). However, CAM includes the request CDB bytes when such occurs, and the bytes I sent with my CDB did not match in any way shape or form what CAM was insisting I had sent. I was doing my testing using "camcontrol cmd", since I didn't want to write a bunch of code if I could at least confirm behaviour with cmd. I was making the assumption that if I gave cmd a 512-byte CDB but only provided, say, 15 or 16 of the initial bytes, that the kernel or CAM layer would zero out the rest of the 512-byte CDB. I asked mav@ and he wasn't sure if this was the case. I've included the Email between him and I below (I hope he doesn't mind). I did not have time to try providing all 512 bytes, but I did remove my erroneous "ff ff" bytes (set to "00 00" instead) and it made no difference. The code I wrote for viewing the ATA Security Feature Set bits works fine (wasn't hard to implement). I based my code on what Linux hdparm had. I can put that patch up on the web, but be aware it's more of a "hack" because /usr/include/sys/ata.h needs certain bits added to it, which I just defined in camcontrol.c for the time being. There's also user interface pieces which are half-written which I need to remove. I wouldn't want people patching their camcontrol for this functionality with a half-ass patch is what I'm saying. :-) icarus# ~jdc/work/camcontrol/camcontrol identify ada0 {...} Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes Security Mode feature set yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify no no unload yes yes free-fall no no data set management (TRIM) yes ATA Security Features Status/Value master password revision 0xfffe locked no frozen no password attempt exceeded no enhanced erase support yes security level high erase unit time 2 minutes enhanced erase unit time 2 minutes -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | Date: Fri, 29 Jul 2011 12:36:21 +0300 From: Alexander Motin To: Jeremy Chadwick Subject: Re: Question about "camcontrol cmd" and ATA CDBs Jeremy Chadwick wrote: > Alexander, > > I've been working on implementing the ATA Security Feature set commands > to camcontrol so folks can accomplish Secure Erase for their SSDs. To > test things, I've been using "camcontrol cmd" to issue ATA CDBs to the > drive along with data/payload, while also following the Linux hdparm > source code (what a mess!). > > However, my drive is continually returning ABRT when issuing command > 0xf1 (SECURITY_SET_PASSWORD) to set the user password. > > The ATA specification states this can happen if the Security feature set > is in LOCKED or FROZEN mode, but that doesn't appear to be true. I've > modified camcontrol to show the state of the Security set features > (IDENTIFY word 128 and friends), so you'll see some extra output below > that isn't in normal camcontrol. > > # ~jdc/work/camcontrol/camcontrol identify ada4 > pass4: ATA-8 SATA 2.x device > pass4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > protocol ATA/ATAPI-8 SATA 2.x > device model INTEL SSDSA2CW080G3 > firmware revision 4PC10302 > serial number CVPR112001WZ080BGN > WWN 500151795950e88f > cylinders 16383 > heads 16 > sectors/track 63 > sector size logical 512, physical 512, offset 0 > LBA supported 156301488 sectors > LBA48 supported 156301488 sectors > PIO supported PIO4 > DMA supported WDMA2 UDMA6 > media RPM non-rotating > > Feature Support Enabled Value Vendor > read ahead yes yes > write cache yes yes > flush cache yes yes > overlap no > Tagged Command Queuing (TCQ) no no > Native Command Queuing (NCQ) yes 32 tags > SMART yes yes > microcode download yes yes > Security Mode feature set yes no > power management yes yes > advanced power management no no > automatic acoustic management no no > media status notification no no > power-up in Standby no no > write-read-verify no no > unload yes yes > free-fall no no > data set management (TRIM) yes > > ATA Security Features Status/Value > master password revision 0xfffe > locked no > frozen no > password attempt exceeded no > enhanced erase support yes > security level high > erase unit time 2 minutes > enhanced erase unit time 2 minutes > > The extra output here comes from bits per master_passwd_revision, > security_status, erase_time, and enhanced_erase_time fields of > ata_params (include/sys/ata.h). > > Here's the camcontrol CDB I'm submitting: > > camcontrol cmd ada4 -v -r - \ > -a "f1 00 00 00 00 00 00 00 00 00 00 00" \ > -o 512 "00 00 45 69 6e 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff" > > The CDB should be: > > command = 0xf1 > feature = unused > count = unused > lba = unused > device = the usual :-) > > The payload should be: > > byte 0 = 0x00 = bits 7-1 = n/a > bit 0 = set USER password identifier > byte 1 = 0x00 = bits 15-9 = n/a > bit 8 = master pass capability HIGH > byte 2-33 = 0x45696e73... = password string ("Eins" in ASCII) > byte 34 = 0xff = low byte of master password revision + 1 > byte 35 = 0xff = high byte of master password revision + 1 Valid from 0001 to fffe. But only in byte 36-511 = I assume CAM zeros these out, so they should be 0x00 ? I haven't experimented. You may try to use 512bytes file. > What I get back: > > camcontrol: error sending command > (pass4:ahcich4:0:0:0): NOP. ACB: 00 00 c0 a0 00 00 00 00 00 58 c0 a0 > (pass4:ahcich4:0:0:0): CAM status: ATA Status Error > (pass4:ahcich4:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) > (pass4:ahcich4:0:0:0): RES: 51 04 c0 a0 00 00 00 00 00 c0 a0 Something is wrong there. You should see your command after "ACB:". > I assume I'm doing something wrong but I've been scratching my head for > a couple hours now trying to figure out the issue. Byte ordering? I'm > not sure. cam_cdbparse() does not do a very good job explaining the > exact ATA CDB byte order. I've power-cycled the device as well to no > avail. CDB byte order described in camcontrol(8). Data block transferred as-is. > Also, the NOP seems to be because src/sys/dev/ata/ata-queue.c lacks > relevant case statements for the Security Feature set commands. I can > submit a simple PR/patch for improving those. To the hell ata-queue.c :) cam/ata/ata_all.c seems has them. -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Fri Aug 5 04:47:40 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFDFA106564A for ; Fri, 5 Aug 2011 04:47:40 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id 5C7A58FC08 for ; Fri, 5 Aug 2011 04:47:39 +0000 (UTC) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta09.westchester.pa.mail.comcast.net with comcast id GUkX1h0020Fqzac59Ungzk; Fri, 05 Aug 2011 04:47:40 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta08.westchester.pa.mail.comcast.net with comcast id GUnT1h00X1t3BNj3UUnUZC; Fri, 05 Aug 2011 04:47:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 05A79102C19; Thu, 4 Aug 2011 21:47:26 -0700 (PDT) Date: Thu, 4 Aug 2011 21:47:26 -0700 From: Jeremy Chadwick To: Steven Hartland Message-ID: <20110805044725.GA48395@icarus.home.lan> References: <13BEC27B17D24D0CBF2E6A98FD3227F3@multiplay.co.uk> <20110728012437.GA23430@icarus.home.lan> <20110728103234.GA33275@icarus.home.lan> <20110728145917.GA37805@icarus.home.lan> <2A07CD8AE6AE49A5BAED59A7E547D1F9@multiplay.co.uk> <2D117F9F212A4CCBA6B7F51E8705BDB7@multiplay.co.uk> <20110805033001.GA47366@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110805033001.GA47366@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Questions about erasing an ssd to restore performance under FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 04:47:40 -0000 On Thu, Aug 04, 2011 at 08:30:01PM -0700, Jeremy Chadwick wrote: > I can put that patch up on the web, but be aware it's more of a "hack" > because /usr/include/sys/ata.h needs certain bits added to it, which I > just defined in camcontrol.c for the time being. There's also user > interface pieces which are half-written which I need to remove. I > wouldn't want people patching their camcontrol for this functionality > with a half-ass patch is what I'm saying. :-) I've cleaned up the patch (removed the half-written usage stuff) and made it available. http://jdc.parodius.com/freebsd/camcontrol_ata_security/ If this is committed to base the #define ATA_SECURITY_* entries should be moved into include/sys/ata.h. Steve, if you want to put up your patch somewhere I can review it, but an official review from someone more familiar with CAM (e.g. mav@) would be best. I'm also not sure how you implemented all the features, UI-wise (command-line-argument-wise). This is what I came up with, from my internal docs, with comparative syntax in Linux hdparm: NOTE: Should try to avoid using -C, -E, -n, -t, -u, or -v camcontrol security -U -p PWD == unlock (--security-unlock PWD) camcontrol security -S -p PWD == set password (--security-set-pass PWD) camcontrol security -D -p PWD == disable (--security-disable PWD) camcontrol security -X -p PWD == erase (--security-erase PWD) camcontrol security -Z -p PWD == enhanced erase (--security-erase-enhanced PWD) camcontrol security -i TYPE ... == {user,master} (--user-master USER) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Fri Aug 5 07:30:18 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44D50106564A for ; Fri, 5 Aug 2011 07:30:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 332B18FC0C for ; Fri, 5 Aug 2011 07:30:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p757UI8i069020 for ; Fri, 5 Aug 2011 07:30:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p757UHus069017; Fri, 5 Aug 2011 07:30:18 GMT (envelope-from gnats) Date: Fri, 5 Aug 2011 07:30:18 GMT Message-Id: <201108050730.p757UHus069017@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Gleb Kurtsou Cc: Subject: Re: kern/159418: [tmpfs] [panic] tmpfs kernel panic: recursing on non recursive lockmgr tmpfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Kurtsou List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 07:30:18 -0000 The following reply was made to PR kern/159418; it has been noted by GNATS. From: Gleb Kurtsou To: bug-followup@FreeBSD.org, gpr@mail.ru Cc: Subject: Re: kern/159418: [tmpfs] [panic] tmpfs kernel panic: recursing on non recursive lockmgr tmpfs Date: Fri, 5 Aug 2011 09:55:50 +0300 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Could you test the patch attached. Thanks, Gleb. --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="tmpfs-rename_lock.patch.txt" --- a/sys/fs/tmpfs/tmpfs_vnops.c +++ b/sys/fs/tmpfs/tmpfs_vnops.c @@ -968,7 +968,7 @@ tmpfs_rename(struct vop_rename_args *v) /* If we need to move the directory between entries, lock the * source so that we can safely operate on it. */ - if (tdvp != fdvp) { + if (fdvp != tdvp && fdvp != tvp) { error = vn_lock(fdvp, LK_EXCLUSIVE | LK_RETRY); if (error != 0) goto out; @@ -1145,7 +1145,7 @@ tmpfs_rename(struct vop_rename_args *v) error = 0; out_locked: - if (fdnode != tdnode) + if (fdvp != tdvp && fdvp != tvp) VOP_UNLOCK(fdvp, 0); out: --UlVJffcvxoiEqYs2-- From owner-freebsd-fs@FreeBSD.ORG Fri Aug 5 08:40:11 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBB341065670 for ; Fri, 5 Aug 2011 08:40:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CA9F98FC1C for ; Fri, 5 Aug 2011 08:40:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p758eBwE045853 for ; Fri, 5 Aug 2011 08:40:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p758eB3E045852; Fri, 5 Aug 2011 08:40:11 GMT (envelope-from gnats) Date: Fri, 5 Aug 2011 08:40:11 GMT Message-Id: <201108050840.p758eB3E045852@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andrei Lavreniyuk Cc: Subject: Re: kern/159418: [tmpfs] [panic] tmpfs kernel panic: recursing on non recursive lockmgr tmpfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrei Lavreniyuk List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 08:40:11 -0000 The following reply was made to PR kern/159418; it has been noted by GNATS. From: Andrei Lavreniyuk To: bug-followup@freebsd.org, gpr@mail.ru Cc: Subject: Re: kern/159418: [tmpfs] [panic] tmpfs kernel panic: recursing on non recursive lockmgr tmpfs Date: Fri, 5 Aug 2011 11:36:45 +0300 Hi! On a system FreeBSD 8.2-STABLE error is present. The patch works fine. FreeBSD datacenter.technica-03.local 8.2-STABLE FreeBSD 8.2-STABLE #0: Thu Aug 4 12:36:33 EEST 2011 root@datacenter.technica-03.local:/usr/obj/usr/src/sys/SMP64 amd64 # cd /tmp # mkdir -p a/a # mv a/a . mv: rename a/a to ./a: Directory not empty # df -h | egrep tmpfs tmpfs 1.0G 16k 1G 0% /tmp --- Best regards, Andrei Lavreniyuk. From owner-freebsd-fs@FreeBSD.ORG Fri Aug 5 09:15:53 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B81A106566C; Fri, 5 Aug 2011 09:15:53 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop01.sare.net (proxypop01.sare.net [194.30.0.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4798FC1A; Fri, 5 Aug 2011 09:15:52 +0000 (UTC) Received: from [172.16.1.55] (izaro.sarenet.es [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPSA id 4A2E763E8CC; Fri, 5 Aug 2011 11:15:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <201108041420.p74EKCbY098803@freefall.freebsd.org> Date: Fri, 5 Aug 2011 11:15:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201108041420.p74EKCbY098803@freefall.freebsd.org> To: Martin Matuska X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 09:15:53 -0000 =09 On Aug 4, 2011, at 4:20 PM, Martin Matuska wrote: > If you remove that code, it will still work the way it should, but = slower :) > I still see no problem in not-prefetching hidden datasets. Yep, the patch seems to work perfectly. I've been trying to trigger the = issue and no way, seems to be solved. Borja. From owner-freebsd-fs@FreeBSD.ORG Fri Aug 5 09:20:09 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D6421065672 for ; Fri, 5 Aug 2011 09:20:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1D93F8FC14 for ; Fri, 5 Aug 2011 09:20:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p759K8aP081689 for ; Fri, 5 Aug 2011 09:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p759K8Fs081688; Fri, 5 Aug 2011 09:20:08 GMT (envelope-from gnats) Date: Fri, 5 Aug 2011 09:20:08 GMT Message-Id: <201108050920.p759K8Fs081688@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Borja Marcos Cc: Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Borja Marcos List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 09:20:09 -0000 The following reply was made to PR kern/157728; it has been noted by GNATS. From: Borja Marcos To: Martin Matuska Cc: freebsd-fs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones Date: Fri, 5 Aug 2011 11:15:07 +0200 =09 On Aug 4, 2011, at 4:20 PM, Martin Matuska wrote: > If you remove that code, it will still work the way it should, but = slower :) > I still see no problem in not-prefetching hidden datasets. Yep, the patch seems to work perfectly. I've been trying to trigger the = issue and no way, seems to be solved. Borja. From owner-freebsd-fs@FreeBSD.ORG Fri Aug 5 10:01:45 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5567A106566B for ; Fri, 5 Aug 2011 10:01:45 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D93198FC0A for ; Fri, 5 Aug 2011 10:01:44 +0000 (UTC) Received: by fxe4 with SMTP id 4so4000673fxe.13 for ; Fri, 05 Aug 2011 03:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=8ojgaarDZLhzrp+GlYK2m1B6Jd5T69dfHMfZMlPgKSc=; b=MfvB27OiEkNvCvfJCXkoSErcVj45RUGhsCFGKTAjbbCtC7vioH7sDlx4vaq9bbGeg8 7032izPT0otgRCOtx/WvwEHcOk0V+bOjdCTUxoF0tS1zeSRFIzaE5bUl4Smt/1LgRfSv ejFFvP4w/7bgNJrl0o/pDROn+ll8pN4lryXrg= Received: by 10.223.15.81 with SMTP id j17mr2652814faa.20.1312536929754; Fri, 05 Aug 2011 02:35:29 -0700 (PDT) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id h9sm1832526faa.39.2011.08.05.02.35.27 (version=SSLv3 cipher=OTHER); Fri, 05 Aug 2011 02:35:28 -0700 (PDT) Date: Fri, 5 Aug 2011 12:35:00 +0300 From: Gleb Kurtsou To: Andrei Lavreniyuk Message-ID: <20110805093500.GA20030@tops> References: <201108050840.p758eB3E045852@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201108050840.p758eB3E045852@freefall.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/159418: [tmpfs] [panic] tmpfs kernel panic: recursing on non recursive lockmgr tmpfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 10:01:45 -0000 On (05/08/2011 08:40), Andrei Lavreniyuk wrote: > The following reply was made to PR kern/159418; it has been noted by GNATS. > > From: Andrei Lavreniyuk > To: bug-followup@freebsd.org, gpr@mail.ru > Cc: > Subject: Re: kern/159418: [tmpfs] [panic] tmpfs kernel panic: recursing on non > recursive lockmgr tmpfs > Date: Fri, 5 Aug 2011 11:36:45 +0300 > > Hi! > > On a system FreeBSD 8.2-STABLE error is present. The patch works fine. > > FreeBSD datacenter.technica-03.local 8.2-STABLE FreeBSD 8.2-STABLE #0: > Thu Aug 4 12:36:33 EEST 2011 > root@datacenter.technica-03.local:/usr/obj/usr/src/sys/SMP64 amd64 > > > # cd /tmp > # mkdir -p a/a > # mv a/a . > mv: rename a/a to ./a: Directory not empty It's expected and consistent with UFS and ZFS. a directory is not empty before rename, it contains a/a. > # df -h | egrep tmpfs > tmpfs 1.0G 16k 1G 0% /tmp > > > > > --- > Best regards, Andrei Lavreniyuk. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Fri Aug 5 10:40:14 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77AD3106564A for ; Fri, 5 Aug 2011 10:40:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4E90E8FC0A for ; Fri, 5 Aug 2011 10:40:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p75AeDEH055040 for ; Fri, 5 Aug 2011 10:40:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p75AeD7Y055039; Fri, 5 Aug 2011 10:40:13 GMT (envelope-from gnats) Date: Fri, 5 Aug 2011 10:40:13 GMT Message-Id: <201108051040.p75AeD7Y055039@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Gennady Proskurin Cc: Subject: Re: kern/159418: [tmpfs] [panic] tmpfs kernel panic: recursing on non recursive lockmgr tmpfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gennady Proskurin List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 10:40:14 -0000 The following reply was made to PR kern/159418; it has been noted by GNATS. From: Gennady Proskurin To: bug-followup@FreeBSD.org, gpr@mail.ru Cc: Subject: Re: kern/159418: [tmpfs] [panic] tmpfs kernel panic: recursing on non recursive lockmgr tmpfs Date: Fri, 5 Aug 2011 14:16:46 +0400 Patch works for me, it fixes panic. Thanks. From owner-freebsd-fs@FreeBSD.ORG Sat Aug 6 00:54:17 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD1B61065740 for ; Sat, 6 Aug 2011 00:54:17 +0000 (UTC) (envelope-from prvs=11992d5f15=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 2C2D08FC1D for ; Sat, 6 Aug 2011 00:54:16 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 06 Aug 2011 01:43:38 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 06 Aug 2011 01:43:37 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014484356.msg for ; Sat, 06 Aug 2011 01:43:36 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11992d5f15=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@FreeBSD.ORG Message-ID: From: "Steven Hartland" To: "Jeremy Chadwick" References: <13BEC27B17D24D0CBF2E6A98FD3227F3@multiplay.co.uk> <20110728012437.GA23430@icarus.home.lan> <20110728103234.GA33275@icarus.home.lan> <20110728145917.GA37805@icarus.home.lan> <2A07CD8AE6AE49A5BAED59A7E547D1F9@multiplay.co.uk> <2D117F9F212A4CCBA6B7F51E8705BDB7@multiplay.co.uk> <20110805033001.GA47366@icarus.home.lan> <20110805044725.GA48395@icarus.home.lan> Date: Sat, 6 Aug 2011 01:44:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Questions about erasing an ssd to restore performance under FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 00:54:17 -0000 ----- Original Message ----- From: "Jeremy Chadwick" > I've cleaned up the patch (removed the half-written usage stuff) and > made it available. > > http://jdc.parodius.com/freebsd/camcontrol_ata_security/ > > If this is committed to base the #define ATA_SECURITY_* entries should > be moved into include/sys/ata.h. > > Steve, if you want to put up your patch somewhere I can review it, but > an official review from someone more familiar with CAM (e.g. mav@) would > be best. > > I'm also not sure how you implemented all the features, > UI-wise (command-line-argument-wise). This is what I came up with, from > my internal docs, with comparative syntax in Linux hdparm: > > NOTE: Should try to avoid using -C, -E, -n, -t, -u, or -v > > camcontrol security -U -p PWD == unlock (--security-unlock PWD) > camcontrol security -S -p PWD == set password (--security-set-pass PWD) > camcontrol security -D -p PWD == disable (--security-disable PWD) > camcontrol security -X -p PWD == erase (--security-erase PWD) > camcontrol security -Z -p PWD == enhanced erase (--security-erase-enhanced PWD) > camcontrol security -i TYPE ... == {user,master} (--user-master USER) Yer I couldn't stand using meaningless short options so added long arg support. The current version of my patch can be found here:- http://blog.multiplay.co.uk/dropzone/freebsd/ata_security_cam.patch If you can find some time to review it Jeremy that would great. I think its all pretty straight forward, the only confusing part of the diff is that I split ataidentify into 3 pieces, ataidentify and the helpers ata_do_idenfity and ata_cam_send to avoid swathes of code duplication. Some more details and usage examples and caveats can be found here:- http://blog.multiplay.co.uk/2011/08/freebsd-security-support-for-ata-devices-via-camcontrol/ I've updated the code as well as the man pages so everything should be good. I've not tested all of the various combinations totally yet, but have tested all the big ones inc secure erase, set pass, set level, set user & disable. It should be noted that this requires disks attached to an ATA controller e.g. ahci as ATA commands don't appear to pass through other controllers e.g. mpt even with ATA disks underneath. I'd be interested to here from anyone who has an info on getting this to work as well. Much credit to Daniel Roethlisberger for his work which was the basis of this code. This can be found here:- http://www.roe.ch/ATA_Security http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/127918 Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Sat Aug 6 04:18:26 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87E50106567A for ; Sat, 6 Aug 2011 04:18:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6F98FC1F for ; Sat, 6 Aug 2011 04:18:25 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta08.westchester.pa.mail.comcast.net with comcast id GsDG1h0041swQuc58sJS00; Sat, 06 Aug 2011 04:18:26 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta15.westchester.pa.mail.comcast.net with comcast id GsJP1h0181t3BNj3bsJQ8H; Sat, 06 Aug 2011 04:18:25 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 42F48102C36; Fri, 5 Aug 2011 21:18:22 -0700 (PDT) Date: Fri, 5 Aug 2011 21:18:22 -0700 From: Jeremy Chadwick To: Steven Hartland Message-ID: <20110806041822.GA11439@icarus.home.lan> References: <20110728012437.GA23430@icarus.home.lan> <20110728103234.GA33275@icarus.home.lan> <20110728145917.GA37805@icarus.home.lan> <2A07CD8AE6AE49A5BAED59A7E547D1F9@multiplay.co.uk> <2D117F9F212A4CCBA6B7F51E8705BDB7@multiplay.co.uk> <20110805033001.GA47366@icarus.home.lan> <20110805044725.GA48395@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Questions about erasing an ssd to restore performance under FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 04:18:26 -0000 On Sat, Aug 06, 2011 at 01:44:02AM +0100, Steven Hartland wrote: > ----- Original Message ----- From: "Jeremy Chadwick" > > >I've cleaned up the patch (removed the half-written usage stuff) and > >made it available. > > > >http://jdc.parodius.com/freebsd/camcontrol_ata_security/ > > > >If this is committed to base the #define ATA_SECURITY_* entries should > >be moved into include/sys/ata.h. > > > >Steve, if you want to put up your patch somewhere I can review it, but > >an official review from someone more familiar with CAM (e.g. mav@) would > >be best. > > > >I'm also not sure how you implemented all the features, > >UI-wise (command-line-argument-wise). This is what I came up with, from > >my internal docs, with comparative syntax in Linux hdparm: > > > >NOTE: Should try to avoid using -C, -E, -n, -t, -u, or -v > > > >camcontrol security -U -p PWD == unlock (--security-unlock PWD) > >camcontrol security -S -p PWD == set password (--security-set-pass PWD) > >camcontrol security -D -p PWD == disable (--security-disable PWD) > >camcontrol security -X -p PWD == erase (--security-erase PWD) > >camcontrol security -Z -p PWD == enhanced erase (--security-erase-enhanced PWD) > >camcontrol security -i TYPE ... == {user,master} (--user-master USER) > > Yer I couldn't stand using meaningless short options so added long arg support. > > The current version of my patch can be found here:- > http://blog.multiplay.co.uk/dropzone/freebsd/ata_security_cam.patch > > If you can find some time to review it Jeremy that would great. I think > its all pretty straight forward, the only confusing part of the diff is > that I split ataidentify into 3 pieces, ataidentify and the helpers > ata_do_idenfity and ata_cam_send to avoid swathes of code duplication. I've spent about an hour going over the patch, and I'm far from done. Comments in passing or things of concern at this point, some of which have nothing to do directly with your work per se. I have not tested your patch either, just for the record (I do have a spare SSD set up solely for this purpose). 1) Focusing on Erase or Enhanced Erase, it appears you set the internal timeout to the number of seconds that matches what the device itself claims to be the duration for the erase to complete (assuming ident_buf->erase_time is non-zero, else you default to 2 hours). I may be misunderstanding the timeout specifier here, but based on what I've read there is no 1:1 correlation between the actual operation timeout and what the drive claims to be the duration of the erase. Please read this entry: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase#Command_time-out_during_erase_with_larger_drives About general timeouts: the hdparm maintainer just recently (September 2010) changed his default timeout value from 5 seconds to 15 seconds, citing that some drives take longer than others. Your patch uses a timeout of 5 seconds, I would advocate increasing that to 15 "just in case". 2) The code logic for setting the master password differs from what Linux hdparm has. Yours says "if revision isn't zero, and revision isn't 0xffff, and revision-1 isn't zero, set revision to 0xfffe": if (0 != pwd.revision && 0xffff != pwd.revision && 0 == --pwd.revision) { pwd.revision = 0xfffe; } Linux hdparm's code says "if revision is 0xffff, then make it zero. If revision isn't 0xffff then don't worry about it. Increment revision." data[] is the 512-byte payload: if (revcode == 0xffff) { revcode = 0; } revcode += 1; data[34] = revcode; data[35] = revcode >> 8; I spent some time looking at ATA8-ACS2 despite spending hours in it last week. All it states is that revision being 0x0000 or 0xffff means the master password feature isn't supported. So that brings into question two things: i) What purpose the 0 != --pwd.revision comparison serves, ii) Why Linux chooses to increment revision rather than set it to something statically. The ATA specification doesn't state what needs to be done here (I'm not surprised). As such, I believe (i) to be unnecessary, and the answer to (ii) is that Linux may be doing this to ensure compatibility with some model of drives. I can't confirm (ii) because the author of hdparm chooses not to use a VCS; he simply uses SourceForge to distribute tarballs. What I'm saying is that there's no source code annotation that I can get at, so I can't find the justification behind the logic in hdparm. Infuriating. 3) The ata_security_password struct contents are passed directly to the device as the CDB payload. My concern with this has to do with big-endian architectures; u_int16_t are used in this struct, and I would imagine the byte order would be different based on architecture. Unless CAM does something magical under the hood...? 4) Do we really need atasecurity_print_time()? (Yes I understand why it exists per se, since it's called twice, but still...) 5) This can be shortened to use ^= instead: pwd.ctrl = pwd.ctrl ^ ATA_SECURITY_PASSWORD_MASTER; 6) I don't know if use of long getopt arguments violates or upsets folks. It doesn't bother me, but it would make the utility seem inconsistent ("everything takes single character switches except this one command, what's up with that?") 7) There are some style(9) issues. The most notable one is that there's inconsistent use of braces on single-operation if() statements. style(9) insists for single-ops braces not be used. (An example would be the above pwd.revision stuff). 8) Code syntax/style differences vs. what's already in the utility. I don't know how much this matters to folks nor do I know what the Project's stance is on stuff like that. Something tells me there is no stance, as for example there's mixed-use of printf() and fprintf(stdout) in camcontrol (the fprintf() makes it more obvious since there are calls to fprintf(stderr), though those should probably use warnx()). 9) Long argument syntax is inconsistent; usage syntax in code uses double hyphens (--arg) while man page uses single (-arg). I know both work, but generally documentation and usage syntax should show double. 10) Can we get rid of MINIMALISTIC? :-) I had a gut feeling it was to decrease utility size to minimise space on floppies and I was right: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/camcontrol/camcontrol.c#rev1.37 Floppy builds were removed with FreeBSD 8.0, so I'm of the opinion all the #ifndef/#endifs can be removed, and the Makefile updated too. This might have to wait until RELENG_7 is officially EOL'd though (February 2013) else any changes to camcontrol in one tag have to be manually back-ported to an earlier tag. > Some more details and usage examples and caveats can be found here:- > http://blog.multiplay.co.uk/2011/08/freebsd-security-support-for-ata-devices-via-camcontrol/ > > I've updated the code as well as the man pages so everything should be good. > > I've not tested all of the various combinations totally yet, but have tested > all the big ones inc secure erase, set pass, set level, set user & disable. > > It should be noted that this requires disks attached to an ATA controller e.g. > ahci as ATA commands don't appear to pass through other controllers e.g. mpt > even with ATA disks underneath. I imagine the pass-through command "stuff" will need to be addressed in each respective driver (mps(4), etc.)). As for "requiring AHCI mode" (sorry if I misread what you meant), that's nonsense. I keep having battles with people online who insist that features like Secure Erase and TRIM don't work unless you use AHCI. For Secure Erase I know for a fact this is utter nonsense because I've done a Secure Erase on Windows (using Intel's SSD Toolbox) with my controller in "Enhanced SATA" (non-AHCI) mode. ATA is ATA, no matter if you're speaking via legacy PATA or AHCI. So I just want to make that clear to folks who might come across this post via Google or what not. > I'd be interested to here from anyone who has an info on getting this to work > as well. > > Much credit to Daniel Roethlisberger for his work which was the basis of this > code. This can be found here:- > http://www.roe.ch/ATA_Security > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/127918 Someone may want to do the same review of those atacontrol(8) modifications as those mentioned above. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sat Aug 6 04:24:30 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B370D106564A for ; Sat, 6 Aug 2011 04:24:30 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA778FC14 for ; Sat, 6 Aug 2011 04:24:30 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta14.westchester.pa.mail.comcast.net with comcast id GsBr1h0031vXlb85EsQWfn; Sat, 06 Aug 2011 04:24:30 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta17.westchester.pa.mail.comcast.net with comcast id GsQU1h0141t3BNj3dsQV0i; Sat, 06 Aug 2011 04:24:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 87BE4102C36; Fri, 5 Aug 2011 21:24:27 -0700 (PDT) Date: Fri, 5 Aug 2011 21:24:27 -0700 From: Jeremy Chadwick To: Steven Hartland Message-ID: <20110806042427.GA13263@icarus.home.lan> References: <20110728103234.GA33275@icarus.home.lan> <20110728145917.GA37805@icarus.home.lan> <2A07CD8AE6AE49A5BAED59A7E547D1F9@multiplay.co.uk> <2D117F9F212A4CCBA6B7F51E8705BDB7@multiplay.co.uk> <20110805033001.GA47366@icarus.home.lan> <20110805044725.GA48395@icarus.home.lan> <20110806041822.GA11439@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110806041822.GA11439@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Questions about erasing an ssd to restore performance under FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 04:24:30 -0000 On Fri, Aug 05, 2011 at 09:18:22PM -0700, Jeremy Chadwick wrote: > 9) Long argument syntax is inconsistent; usage syntax in code uses > double hyphens (--arg) while man page uses single (-arg). I know both > work, but generally documentation and usage syntax should show double. I stand corrected -- I wasn't aware the *roff ".Op Fl" command prepended a hyphen. So this item isn't an issue. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sat Aug 6 12:52:02 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AAF5106564A for ; Sat, 6 Aug 2011 12:52:02 +0000 (UTC) (envelope-from prvs=11992d5f15=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 840708FC0C for ; Sat, 6 Aug 2011 12:52:01 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 06 Aug 2011 13:51:14 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 06 Aug 2011 13:51:14 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014488332.msg for ; Sat, 06 Aug 2011 13:51:14 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11992d5f15=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@FreeBSD.ORG Message-ID: <42162705FC5E4E748A1A57285AECA49A@multiplay.co.uk> From: "Steven Hartland" To: "Jeremy Chadwick" References: <20110728012437.GA23430@icarus.home.lan> <20110728103234.GA33275@icarus.home.lan> <20110728145917.GA37805@icarus.home.lan> <2A07CD8AE6AE49A5BAED59A7E547D1F9@multiplay.co.uk> <2D117F9F212A4CCBA6B7F51E8705BDB7@multiplay.co.uk> <20110805033001.GA47366@icarus.home.lan> <20110805044725.GA48395@icarus.home.lan> <20110806041822.GA11439@icarus.home.lan> Date: Sat, 6 Aug 2011 13:51:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Questions about erasing an ssd to restore performance under FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 12:52:02 -0000 ----- Original Message ----- From: "Jeremy Chadwick" > 1) Focusing on Erase or Enhanced Erase, it appears you set the internal > timeout to the number of seconds that matches what the device itself > claims to be the duration for the erase to complete (assuming > ident_buf->erase_time is non-zero, else you default to 2 hours). I may > be misunderstanding the timeout specifier here, but based on what I've > read there is no 1:1 correlation between the actual operation timeout > and what the drive claims to be the duration of the erase. Please read > this entry: > > https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase#Command_time-out_during_erase_with_larger_drives > According to the spec the values mean the following:- 0 = unspecified 1-254 = (value*2) minutes 255 = >508 minutes > About general timeouts: the hdparm maintainer just recently (September > 2010) changed his default timeout value from 5 seconds to 15 seconds, > citing that some drives take longer than others. Your patch uses a > timeout of 5 seconds, I would advocate increasing that to 15 "just in > case". Changed longer I suspect is generally safer as you say. > 2) The code logic for setting the master password differs from what > Linux hdparm has. Yours says "if revision isn't zero, and revision > isn't 0xffff, and revision-1 isn't zero, set revision to 0xfffe": > > if (0 != pwd.revision && 0xffff != pwd.revision && 0 == --pwd.revision) { > pwd.revision = 0xfffe; > } The logic here is:- if not 0 and not 0xffff then decrement if decrement goes to 0 set it 0xffffe The reason for doing this is that drives which support this options have the value initialised to 0xffffe so decrementing makes more sence than incrementing. The same wrapping is achieved just in a simpler block. > i) What purpose the 0 != --pwd.revision comparison serves, If the decrement hits 0 wrap it to prevent it hitting 0 otherwise it would leave the drive in a state which indicates "not supported" > ii) Why Linux chooses to increment revision rather than set it to > something statically. They increment this decrments, I beleive the important thing is change, which they both achieve. > The ATA specification doesn't state what needs to be done here (I'm not > surprised). As such, I believe (i) to be unnecessary, and the answer to > (ii) is that Linux may be doing this to ensure compatibility with some > model of drives. I can't confirm (ii) because the author of hdparm > chooses not to use a VCS; he simply uses SourceForge to distribute > tarballs. What I'm saying is that there's no source code annotation > that I can get at, so I can't find the justification behind the logic in > hdparm. Infuriating. >From what I can tell its just mechanisum for external tools to tell if the master password is the same one they encountered last time, hence the increment or decrement, as that ensures its changing on each master password set. > 3) The ata_security_password struct contents are passed directly to the > device as the CDB payload. My concern with this has to do with > big-endian architectures; u_int16_t are used in this struct, and I > would imagine the byte order would be different based on architecture. > Unless CAM does something magical under the hood...? Disk hardware I suspect is one or the other not a mix like cpus, I'm unsure, but I dont see any other manipulation of endian in any other tools. Would need someone who knows to comment. > 4) Do we really need atasecurity_print_time()? (Yes I understand why it > exists per se, since it's called twice, but still...) Don't like duplicate code personaly ;-) > 5) This can be shortened to use ^= instead: > > pwd.ctrl = pwd.ctrl ^ ATA_SECURITY_PASSWORD_MASTER; Of course changed > > 6) I don't know if use of long getopt arguments violates or upsets > folks. It doesn't bother me, but it would make the utility seem > inconsistent ("everything takes single character switches except this > one command, what's up with that?") Given the nature of the options I would personally prefer they where understandable over shorter. It could be changed but I'd prefer not to. > > 7) There are some style(9) issues. The most notable one is that there's > inconsistent use of braces on single-operation if() statements. > style(9) insists for single-ops braces not be used. (An example would > be the above pwd.revision stuff). IIRC it stats they can > > 8) Code syntax/style differences vs. what's already in the utility. I > don't know how much this matters to folks nor do I know what the > Project's stance is on stuff like that. Something tells me there is no > stance, as for example there's mixed-use of printf() and fprintf(stdout) > in camcontrol (the fprintf() makes it more obvious since there are calls > to fprintf(stderr), though those should probably use warnx()). Yes I noticed that the code, and went with warnx and fprintf(stdout looks like its evolved over time. If there is a preference I'm happy to change. > 9) Long argument syntax is inconsistent; usage syntax in code uses > double hyphens (--arg) while man page uses single (-arg). I know both > work, but generally documentation and usage syntax should show double. thats just how man works, if you look at the output it actually prints --option not -option. > 10) Can we get rid of MINIMALISTIC? :-) I had a gut feeling it was to > decrease utility size to minimise space on floppies and I was right: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/camcontrol/camcontrol.c#rev1.37 > Floppy builds were removed with FreeBSD 8.0, so I'm of the opinion all > the #ifndef/#endifs can be removed, and the Makefile updated too. This > might have to wait until RELENG_7 is officially EOL'd though (February > 2013) else any changes to camcontrol in one tag have to be manually > back-ported to an earlier tag. Quite possibly but should be done as a seperate commit imo to make it clear, hence maintaining the compat with the current convention in the patch. >> Some more details and usage examples and caveats can be found here:- >> http://blog.multiplay.co.uk/2011/08/freebsd-security-support-for-ata-devices-via-camcontrol/ >> >> I've updated the code as well as the man pages so everything should be good. >> >> I've not tested all of the various combinations totally yet, but have tested >> all the big ones inc secure erase, set pass, set level, set user & disable. >> >> It should be noted that this requires disks attached to an ATA controller e.g. >> ahci as ATA commands don't appear to pass through other controllers e.g. mpt >> even with ATA disks underneath. > > I imagine the pass-through command "stuff" will need to be addressed in > each respective driver (mps(4), etc.)). I do see mps mention passthough but it doesnt seem to work even with just identify after I switched the logic around to default to ATA instead of ATAPI. Need to do some more investigation. > As for "requiring AHCI mode" (sorry if I misread what you meant), that's > nonsense. I keep having battles with people online who insist that > features like Secure Erase and TRIM don't work unless you use AHCI. For > Secure Erase I know for a fact this is utter nonsense because I've done > a Secure Erase on Windows (using Intel's SSD Toolbox) with my controller > in "Enhanced SATA" (non-AHCI) mode. ATA is ATA, no matter if you're > speaking via legacy PATA or AHCI. So I just want to make that clear to > folks who might come across this post via Google or what not. I don't mean that its needed I just mean it needs ATA command compatiblity hence the "ATA controller such as ahci" with the key word being "such" ;-) >> I'd be interested to here from anyone who has an info on getting this to >> work as well. >> >> Much credit to Daniel Roethlisberger for his work which was the basis >> of this code. This can be found here:- >> http://www.roe.ch/ATA_Security >> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/127918 > > Someone may want to do the same review of those atacontrol(8) > modifications as those mentioned above. Unfortunately it was never committed, due to the freeze on ata with the migration to cam apparently. I've updated the patch file with the changes mentioned above. Thanks for doing the review most appreciated :) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.