From owner-freebsd-fs@freebsd.org Sun May 1 18:03:22 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 855DAB29985 for ; Sun, 1 May 2016 18:03:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 766021838 for ; Sun, 1 May 2016 18:03:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u41I3LVD019875 for ; Sun, 1 May 2016 18:03:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 207464] Panic when destroying ZFS snapshot on boot filesystem Date: Sun, 01 May 2016 18:03:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: harrison@glsan.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 18:03:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207464 --- Comment #10 from harrison@glsan.com --- This bug is a major bug causing all my systems to reboot regularly, impacti= ng production nfs servers. Thoughts for how to fix the problem are welcomed. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun May 1 21:00:25 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FE7FB29293 for ; Sun, 1 May 2016 21:00:25 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D10B1059 for ; Sun, 1 May 2016 21:00:25 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u41L0180072451 for ; Sun, 1 May 2016 21:00:25 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201605012100.u41L0180072451@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention Date: Sun, 01 May 2016 21:00:25 +0000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 21:00:25 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 203492 | mount_unionfs -o below causes panic Open | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f 4 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Mon May 2 02:56:10 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 327C8B2A456 for ; Mon, 2 May 2016 02:56:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 237CC1EC3 for ; Mon, 2 May 2016 02:56:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u422u9XG045576 for ; Mon, 2 May 2016 02:56:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 209158] node / npm triggering zfs rename deadlock Date: Mon, 02 May 2016 02:56:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 02:56:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209158 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon May 2 02:57:34 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DAF8B2A5C6 for ; Mon, 2 May 2016 02:57:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5EF1810F8 for ; Mon, 2 May 2016 02:57:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u422vXZP082703 for ; Mon, 2 May 2016 02:57:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 209096] zfsroot bricked on 10.3-RELEASE Date: Mon, 02 May 2016 02:57:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 02:57:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209096 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon May 2 02:57:42 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EEBC9B2A607 for ; Mon, 2 May 2016 02:57:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF9E811C1 for ; Mon, 2 May 2016 02:57:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u422vgCq086083 for ; Mon, 2 May 2016 02:57:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 209093] ZFS snapshot rename : .zfs/snapshot messes up Date: Mon, 02 May 2016 02:57:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 02:57:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209093 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon May 2 07:53:43 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1755CB2AF19 for ; Mon, 2 May 2016 07:53:43 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE8DF10E9 for ; Mon, 2 May 2016 07:53:42 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-yw0-x244.google.com with SMTP id v81so18462455ywa.2 for ; Mon, 02 May 2016 00:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=1HDs2mS6VZkE0rSFrjn3UJNGFQfnf0NeOWqDEIh/j+Y=; b=ic8Z9lN5CdmwMMVwRQu/8F9V6O8B4D5bft2NDonqseqiS8JN7GT2aiMqVFhht4mAQk S+dcHUPXBnoA+c5mp7HE/vn7OeiZftzCi5KveZzf05oa2MKF/F4UxWQc9Nh6Gl46HV84 CXIzVtrzfZG4c99mqBYkz8YfXxztJ026RkWDLjKhVi61LLHSA5A+05yywm+sYkpNS/hw X2/DuAI2yITnbac+fttPq0W88dxEZ2Gp5E8TNRwcJqeofQtp9IXl7R8xESFp/UslA7Wx eZ3NOEfdhWBLGUN7WOPdqXgG5UIJ4KWWtUnMeOM5rCEzL//+8qWBdTqlA0W28i9xhFa7 +Q/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=1HDs2mS6VZkE0rSFrjn3UJNGFQfnf0NeOWqDEIh/j+Y=; b=B7DYJo4yo3M8eLFaUlDAqfu6WMgiBeD+uveUS1Jzn+dil3PES1iJPedc+OGA4wLhOY gdhymh18bB6gIYJs9Eoy24E84AIfca72cVAWZQf24QQWeRfBs2zBdhmhtjXbSe5sF4wL 4F5OByqrbPCHeWTN1vibCr4ylfBHRi9kRcWMfq/TFRfVBcgPMrq41SkdFlWH2Xoz6u4I hgTBJa4F+A5icg0RRu1rVUzRIKRSeImMKndBooWJBOWALoCUSnxZQD8/Ms/utInGTIgQ Oh5i3YcHFvVnxVrFihbxFhHafrGXYLj7zLbjMbh8idseva4FY9KtFk92s3b/2fHT7UMD D2pg== X-Gm-Message-State: AOPr4FVs3O+1sMrrsk7f5TWG4IHzcXCiUuJbxvypn5OvYuNQMiyyrqzd6siP5At3YhvM3zU58t6z+F35br183Q== MIME-Version: 1.0 X-Received: by 10.176.2.52 with SMTP id 49mr20565616uas.39.1462175622063; Mon, 02 May 2016 00:53:42 -0700 (PDT) Received: by 10.159.34.229 with HTTP; Mon, 2 May 2016 00:53:41 -0700 (PDT) Date: Mon, 2 May 2016 03:53:41 -0400 Message-ID: Subject: zpool import blows up wired vm.kmem_size From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 07:53:43 -0000 10.3-release i386 2GB pentium4 vm.kmem_size=720000000 Needed to keep bumping kmem up to accomodate other zpools. That's the upper limit that will boot on this box. Then got rid of all but one zpool... NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT pool1 232G 228G 3.64G 98% 1.00x ONLINE - pool1 with 6 zfs filesystems with 6+ million inodes. When import attempt, wired mem will hover around 75M for a minute, then jump in a few seconds to about 180M and sit for a few sec, then jump straight to 700+M or so within a second, then the box just sits there with some z-thread[s] stuck in 'kmem a' top state. ARC was only in the low 10M's which sounds fine since no file reads. zpool import -o readonly=on imports through to auto mounting ok. Only read-write blows kmem up and never mounts or returns. Obviously will copy data off it, and off i386. I think it's having problems cleaning up previous writes that hit kmem / powerfail and rebooted. But why the instantaneous jumps in kmem size though? Is this the equivalent of fsck running out of userspace ram on bigfs back in the day, but now zfs in kernel space? From owner-freebsd-fs@freebsd.org Mon May 2 13:51:10 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B90EFB29D3B for ; Mon, 2 May 2016 13:51:10 +0000 (UTC) (envelope-from juan@tf.uni-kiel.de) Received: from mhost.tf.uni-kiel.de (mhost.tf.uni-kiel.de [134.245.247.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 473921897 for ; Mon, 2 May 2016 13:51:09 +0000 (UTC) (envelope-from juan@tf.uni-kiel.de) Received: from amavis.tf.uni-kiel.de (unknown [192.168.247.79]) by mhost.tf.uni-kiel.de (Postfix) with ESMTP id D2CCFBA946E for ; Mon, 2 May 2016 15:41:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at tf.uni-kiel.de Received: from mhost.tf.uni-kiel.de ([134.245.247.71]) by amavis.tf.uni-kiel.de (amavis.tf.uni-kiel.de [192.168.247.79]) (amavisd-new, port 10025) with ESMTP id Qu9I2Qv0lO0k for ; Mon, 2 May 2016 15:40:59 +0200 (CEST) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mhost.tf.uni-kiel.de (Postfix) with ESMTPSA id 09D2EBA943C for ; Mon, 2 May 2016 15:40:59 +0200 (CEST) Received: by mail-oi0-f51.google.com with SMTP id x19so189277332oix.2 for ; Mon, 02 May 2016 06:40:58 -0700 (PDT) X-Gm-Message-State: AOPr4FXytrpkO9DULaKGulmwOWx9J3bhMTny6lHuQ/1EaVJBTUaNJ3ppbxfurhabEqIj4szI65wL29uB8x8d5g== MIME-Version: 1.0 X-Received: by 10.157.59.3 with SMTP id z3mr13456789otb.173.1462196457227; Mon, 02 May 2016 06:40:57 -0700 (PDT) Received: by 10.157.9.8 with HTTP; Mon, 2 May 2016 06:40:57 -0700 (PDT) Date: Mon, 2 May 2016 15:40:57 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Mounting FreeBSD NFSv4 share on Linux using krb5 From: Julian Andrej To: freebsd-fs@freebsd.org, rmacklem@uoguelph.ca Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 13:51:10 -0000 Hello, i'm desperately trying to mount a nfsv4 export from FreeBSD on a Linux client using sec=krb5. So my setup is as follows: FreeBSD host which is the KDC. Linux client which can auth via kerberos and should be able to mount the nfs share. Mounting the share with sec=krb5 from FreeBSD on another FreeBSD box is no problem, but it fails on the linux client. The client fails with $ sudo mount -t nfs4 -o sec=krb5 ***:/tank/homes mnt -vv mount.nfs4: timeout set for Mon May 2 15:39:19 2016 mount.nfs4: trying text-based options 'sec=krb5,addr=***,clientaddr=***' mount.nfs4: mount(2): Input/output error mount.nfs4: mount system call failed and on the FreeBSD host i get the message gssd_pname_to_uid: failed major=0xd0000 minor=-1765328227 gssd_release_name: done major=0x0 minor=0 gssd_release_cred: done major=0x0 minor=0 which translates to KRB5_NO_LOCALNAME. I have the appropriate principals with nfs/* for the host and client! I have tried heimdal from base and MIT krb5 from ports. Both show the same behavior. The actual kernel log from linux is: Mai 02 15:37:19 *** kernel: NFS: nfs4_discover_server_trunking unhandled error -121. Exiting with error EIO Can anyone guide me to a possible solution here? Regards Julian From owner-freebsd-fs@freebsd.org Mon May 2 23:57:49 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71302B2AE22 for ; Mon, 2 May 2016 23:57:49 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED781CCF for ; Mon, 2 May 2016 23:57:48 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:I3zMzRNVKvg6qL8ffiAl6mtUPXoX/o7sNwtQ0KIMzox0KPv9rarrMEGX3/hxlliBBdydsKIUzbuM+Pq5EUU7or+/81k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ35Txhrr5ocSbSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t4XXskzhUA+O731Ue2MaiBdKS1zH8Rj8dov/9Db8t69+2SSee8H7G+MaQzOnup1qQxygrS4MNDo09SmDkMl5h6FfrReJuhtw3oPQeIHTP/MoLfCVRs8TWWcUBpUZbCdGGI7pKtJXV+c= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DOAQAI6SdX/61jaINehQ65dQENgXaGEAKBbxQBAQEBAQEBAWQngi2CFAEBAQMBIwRSBQsCAQgOCgICDRkCAlcCBC6IBwiqEZEbAQEBAQEBAQMBAQEBAQEafIUlgX6CToQngxaCVgWHdIcViQudKY8vAh4BAUKEByCIOH8BAQE X-IronPort-AV: E=Sophos;i="5.24,570,1454994000"; d="scan'208";a="281292785" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 02 May 2016 19:57:42 -0400 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 2A61315F565; Mon, 2 May 2016 19:57:42 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id k3Fb-xdTa9zG; Mon, 2 May 2016 19:57:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 8D29A15F56E; Mon, 2 May 2016 19:57:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3rBffCkqD_qm; Mon, 2 May 2016 19:57:41 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 6945915F565; Mon, 2 May 2016 19:57:41 -0400 (EDT) Date: Mon, 2 May 2016 19:57:41 -0400 (EDT) From: Rick Macklem To: Julian Andrej Cc: freebsd-fs@freebsd.org Message-ID: <1208197890.85963163.1462233461385.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: Subject: Re: Mounting FreeBSD NFSv4 share on Linux using krb5 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF45 (Win)/8.0.9_GA_6191) Thread-Topic: Mounting FreeBSD NFSv4 share on Linux using krb5 Thread-Index: 4ZFqSXNEWLCUxiJGC7t0/nNDSClxfQ== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 23:57:49 -0000 Julian Andrej wrote: > Hello, > > i'm desperately trying to mount a nfsv4 export from FreeBSD on a Linux > client using sec=krb5. > > So my setup is as follows: > FreeBSD host which is the KDC. Linux client which can auth via > kerberos and should be able to mount the nfs share. > > Mounting the share with sec=krb5 from FreeBSD on another FreeBSD box > is no problem, but it fails on the linux client. The client fails with > > $ sudo mount -t nfs4 -o sec=krb5 ***:/tank/homes mnt -vv > mount.nfs4: timeout set for Mon May 2 15:39:19 2016 > mount.nfs4: trying text-based options 'sec=krb5,addr=***,clientaddr=***' > mount.nfs4: mount(2): Input/output error > mount.nfs4: mount system call failed > > and on the FreeBSD host i get the message > > gssd_pname_to_uid: failed major=0xd0000 minor=-1765328227 The host based credential maps to "nobody", since it isn't in the passwd database. I'm not sure, but I think that is all this is saying (ie. not what is causing the mount to fail). Someone else discovered that a Linux client actually used krb5i even when krb5 was specified. --> Make sure the /etc/exports on the FreeBSD server specifies sec=krb5i,krb5 (and not sec=krb5) --> This will work around this issue. - If you already have both krb5,krb5i specified in your /etc/exports then I have no idea what the failure is. - A first step is capturing packets (all of them and not just the NFS ones) and then looking at them in wireshark. Hopefully that will give you some idea where it is failing. Good luck. It can bvery difficult to figure out what is causing the failure. Linux clients have been known to work, but I have no idea if all/current ones do? rick > gssd_release_name: done major=0x0 minor=0 > gssd_release_cred: done major=0x0 minor=0 > > which translates to KRB5_NO_LOCALNAME. I have the appropriate > principals with nfs/* for the host and client! > > I have tried heimdal from base and MIT krb5 from ports. Both show the > same behavior. > > The actual kernel log from linux is: > Mai 02 15:37:19 *** kernel: NFS: nfs4_discover_server_trunking > unhandled error -121. Exiting with error EIO > > Can anyone guide me to a possible solution here? > > Regards > Julian > From owner-freebsd-fs@freebsd.org Tue May 3 06:27:36 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C81EFB2BE48 for ; Tue, 3 May 2016 06:27:36 +0000 (UTC) (envelope-from juan@tf.uni-kiel.de) Received: from mhost.tf.uni-kiel.de (mhost.tf.uni-kiel.de [134.245.247.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5313B1FCA for ; Tue, 3 May 2016 06:27:35 +0000 (UTC) (envelope-from juan@tf.uni-kiel.de) Received: from amavis.tf.uni-kiel.de (unknown [192.168.247.79]) by mhost.tf.uni-kiel.de (Postfix) with ESMTP id 49A69ED80EC for ; Tue, 3 May 2016 08:27:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at tf.uni-kiel.de Received: from mhost.tf.uni-kiel.de ([134.245.247.71]) by amavis.tf.uni-kiel.de (amavis.tf.uni-kiel.de [192.168.247.79]) (amavisd-new, port 10025) with ESMTP id L_CzUOyrBWYc for ; Tue, 3 May 2016 08:27:23 +0200 (CEST) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mhost.tf.uni-kiel.de (Postfix) with ESMTPSA id 82473ED80DF for ; Tue, 3 May 2016 08:27:23 +0200 (CEST) Received: by mail-oi0-f44.google.com with SMTP id k142so13383246oib.1 for ; Mon, 02 May 2016 23:27:22 -0700 (PDT) X-Gm-Message-State: AOPr4FUV+7Dg/46A+ub+7ZE38CBN+CYvZpuc0OguVmNbyPIn1m7DrCvijKW0X9AU3tBAZ+v8RvXRycsS9557Wg== MIME-Version: 1.0 X-Received: by 10.157.42.199 with SMTP id e65mr241595otb.96.1462256841715; Mon, 02 May 2016 23:27:21 -0700 (PDT) Received: by 10.157.9.8 with HTTP; Mon, 2 May 2016 23:27:21 -0700 (PDT) In-Reply-To: <1208197890.85963163.1462233461385.JavaMail.zimbra@uoguelph.ca> References: <1208197890.85963163.1462233461385.JavaMail.zimbra@uoguelph.ca> Date: Tue, 3 May 2016 08:27:21 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Mounting FreeBSD NFSv4 share on Linux using krb5 From: Julian Andrej To: Rick Macklem Cc: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 06:27:36 -0000 Thanks. I will try your suggestions. I got the mount working adding "-o vers=3" to the mount. But i have not enough experience to really figure out if the "handshake" worked. This way i can mount the share AND i need a user TGT to access the mount, so i guess this i correct? On Tue, May 3, 2016 at 1:57 AM, Rick Macklem wrote: > Julian Andrej wrote: >> Hello, >> >> i'm desperately trying to mount a nfsv4 export from FreeBSD on a Linux >> client using sec=krb5. >> >> So my setup is as follows: >> FreeBSD host which is the KDC. Linux client which can auth via >> kerberos and should be able to mount the nfs share. >> >> Mounting the share with sec=krb5 from FreeBSD on another FreeBSD box >> is no problem, but it fails on the linux client. The client fails with >> >> $ sudo mount -t nfs4 -o sec=krb5 ***:/tank/homes mnt -vv >> mount.nfs4: timeout set for Mon May 2 15:39:19 2016 >> mount.nfs4: trying text-based options 'sec=krb5,addr=***,clientaddr=***' >> mount.nfs4: mount(2): Input/output error >> mount.nfs4: mount system call failed >> >> and on the FreeBSD host i get the message >> >> gssd_pname_to_uid: failed major=0xd0000 minor=-1765328227 > The host based credential maps to "nobody", since it isn't in > the passwd database. I'm not sure, but I think that is all this > is saying (ie. not what is causing the mount to fail). > > Someone else discovered that a Linux client actually used krb5i even > when krb5 was specified. > --> Make sure the /etc/exports on the FreeBSD server specifies > sec=krb5i,krb5 (and not sec=krb5) > --> This will work around this issue. > - If you already have both krb5,krb5i specified in your /etc/exports > then I have no idea what the failure is. > - A first step is capturing packets (all of them and not just the > NFS ones) and then looking at them in wireshark. Hopefully that > will give you some idea where it is failing. > > Good luck. It can bvery difficult to figure out what is causing the > failure. Linux clients have been known to work, but I have no idea if > all/current ones do? > > rick > >> gssd_release_name: done major=0x0 minor=0 >> gssd_release_cred: done major=0x0 minor=0 >> >> which translates to KRB5_NO_LOCALNAME. I have the appropriate >> principals with nfs/* for the host and client! >> >> I have tried heimdal from base and MIT krb5 from ports. Both show the >> same behavior. >> >> The actual kernel log from linux is: >> Mai 02 15:37:19 *** kernel: NFS: nfs4_discover_server_trunking >> unhandled error -121. Exiting with error EIO >> >> Can anyone guide me to a possible solution here? >> >> Regards >> Julian >> From owner-freebsd-fs@freebsd.org Tue May 3 12:32:34 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89B3CB2BC79 for ; Tue, 3 May 2016 12:32:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1D8AE1894 for ; Tue, 3 May 2016 12:32:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:aTgEvhIpgBtwfvDTMdmcpTZWNBhigK39O0sv0rFitYgULfrxwZ3uMQTl6Ol3ixeRBMOAu6MC07Kd6PuocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC3oLvj6vpoNX6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFmrPHs4DveSQqG4DM1VGkMnxgAVwrY5RfSQpm3ry378+l81S3cMcCgHp4uXjH31aZgS1fNgSwEMzM8uDXNj8V7j6ZWpTq8oBNizorMYMeePawtLevmYdoGSD8ZDY5qXCtbD9b5NtNXAg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2A7AgAmmShX/61jaINehAt9AQW6CgENgXYkhWwCgXcUAQEBAQEBAQFkJ4ItghQBAQEDASMEUgULAgEIDgoCAg0ZAgJXAgQTG4gHCA6peZEiAQEBAQEBBAEBAQEBARp8hSWBfoJPhCmDFoJZBYd1hxWJDIV8ilKMXI8wAh4BAUKEByAwAYc8fwEBAQ X-IronPort-AV: E=Sophos;i="5.24,572,1454994000"; d="scan'208";a="281345599" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 03 May 2016 08:32:31 -0400 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 08FD515F565; Tue, 3 May 2016 08:32:31 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id gYFxYlKFArvy; Tue, 3 May 2016 08:32:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 1E03615F56E; Tue, 3 May 2016 08:32:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YS0TwwHqsQF0; Tue, 3 May 2016 08:32:30 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id F2B7815F565; Tue, 3 May 2016 08:32:29 -0400 (EDT) Date: Tue, 3 May 2016 08:32:29 -0400 (EDT) From: Rick Macklem To: Julian Andrej Cc: freebsd-fs@freebsd.org Message-ID: <182310165.86321733.1462278749938.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: <1208197890.85963163.1462233461385.JavaMail.zimbra@uoguelph.ca> Subject: Re: Mounting FreeBSD NFSv4 share on Linux using krb5 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF45 (Win)/8.0.9_GA_6191) Thread-Topic: Mounting FreeBSD NFSv4 share on Linux using krb5 Thread-Index: FYhWx9+YBsbJkH4dG3HUNuqITVd9JA== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 12:32:34 -0000 Julian Andrej wrote: > Thanks. I will try your suggestions. I got the mount working adding > "-o vers=3" to the mount. But i have not enough experience to really > figure out if the "handshake" worked. This way i can mount the share > AND i need a user TGT to access the mount, so i guess this i correct? > That is correct. At least for the FreeBSD client (and I think the Linux one is the same), not host-based client credential is needed for a NFSv3 kerberized mount. (The host based credential is used for the NFSv4 state related ops and there are none of those for NFSv3.) Basically if the NFSv3 mount works and a user with a valid TGT can access their files, the krb5 stuff is working. Normally for NFSv4 you need a user TGT as well, to access files after the mount is done. --> Hopefully the addition of "krb5i" will fix the NFSv4 case, since the guy who found this mentioned NFSv3 worked ok. Btw, the little patch in head under r298523 might help, although the original reporter didn't report back w.r.t. whether it helped. http://svnweb.freebsd.org/base/head/sys/fs/nfsserver/nfs_nfsdsubs.c?r1=297793&r2=298523 > On Tue, May 3, 2016 at 1:57 AM, Rick Macklem wrote: > > Julian Andrej wrote: > >> Hello, > >> > >> i'm desperately trying to mount a nfsv4 export from FreeBSD on a Linux > >> client using sec=krb5. > >> > >> So my setup is as follows: > >> FreeBSD host which is the KDC. Linux client which can auth via > >> kerberos and should be able to mount the nfs share. > >> > >> Mounting the share with sec=krb5 from FreeBSD on another FreeBSD box > >> is no problem, but it fails on the linux client. The client fails with > >> > >> $ sudo mount -t nfs4 -o sec=krb5 ***:/tank/homes mnt -vv > >> mount.nfs4: timeout set for Mon May 2 15:39:19 2016 > >> mount.nfs4: trying text-based options 'sec=krb5,addr=***,clientaddr=***' > >> mount.nfs4: mount(2): Input/output error > >> mount.nfs4: mount system call failed > >> > >> and on the FreeBSD host i get the message > >> > >> gssd_pname_to_uid: failed major=0xd0000 minor=-1765328227 > > The host based credential maps to "nobody", since it isn't in > > the passwd database. I'm not sure, but I think that is all this > > is saying (ie. not what is causing the mount to fail). > > > > Someone else discovered that a Linux client actually used krb5i even > > when krb5 was specified. > > --> Make sure the /etc/exports on the FreeBSD server specifies > > sec=krb5i,krb5 (and not sec=krb5) > > --> This will work around this issue. > > - If you already have both krb5,krb5i specified in your /etc/exports > > then I have no idea what the failure is. > > - A first step is capturing packets (all of them and not just the > > NFS ones) and then looking at them in wireshark. Hopefully that > > will give you some idea where it is failing. > > > > Good luck. It can bvery difficult to figure out what is causing the > > failure. Linux clients have been known to work, but I have no idea if > > all/current ones do? > > > > rick > > > >> gssd_release_name: done major=0x0 minor=0 > >> gssd_release_cred: done major=0x0 minor=0 > >> > >> which translates to KRB5_NO_LOCALNAME. I have the appropriate > >> principals with nfs/* for the host and client! > >> > >> I have tried heimdal from base and MIT krb5 from ports. Both show the > >> same behavior. > >> > >> The actual kernel log from linux is: > >> Mai 02 15:37:19 *** kernel: NFS: nfs4_discover_server_trunking > >> unhandled error -121. Exiting with error EIO > >> > >> Can anyone guide me to a possible solution here? > >> > >> Regards > >> Julian > >> > From owner-freebsd-fs@freebsd.org Wed May 4 23:31:09 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD59BB2D683 for ; Wed, 4 May 2016 23:31:09 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: from mail-ob0-x242.google.com (mail-ob0-x242.google.com [IPv6:2607:f8b0:4003:c01::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A58B31BCD for ; Wed, 4 May 2016 23:31:09 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: by mail-ob0-x242.google.com with SMTP id ds10so3862734obb.3 for ; Wed, 04 May 2016 16:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=BPI/FivDrao+Dlm3aNzPH7o0sR6wlV73wEru/if5MGs=; b=TFeA3KvkilGJ13VO5Ytoy597pGufZYHLnqCkHZ03NmU6OrGOmygtdVwU3x4SBKfej4 j9+g4E2vMhfnxfBKL0HxdD8qAYOsSinSlE7bTgonCIaN7b2m86tL6mnFEqRO4ib8mQU/ LxSe+eNSvWaqOOxiFlmrFCtuZxGh1q2rYGWMi4vWdPLLUImUJK+KkGu1cLflCsCMfUif FleVqesCicS95k4FRMfvHamshevK4awoIeZ0st1Vis1Mmk5D1FQcDKIck+5kPdyoeP4R MeOKr0mDg+x0fdt0B90rVwXYjst8T3ghs3IyvDv/LKlZCrYFVKy1tTvTE+5sQ1GeQEKn SdVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=BPI/FivDrao+Dlm3aNzPH7o0sR6wlV73wEru/if5MGs=; b=gAgvNRGuUVA8cHJPe974HxGePRQwKz+5wBoQKIqeFS8JWVHXCUQzXPFOttBDX0nCtY kJvHfK4nmw/ZW+TzoW7qQafgK/oD4/LmWcFiU43v9iiRNpqGQJiCkfvfoxDX0T2/ntip amhuxOmiEMrhR9zcIdNEi/iBzHoSap2z+G+lIiYbpEzvypoWIQ8I98SzA6M1vCBXEJDP +Q/SHiK7EsQ6Eo/Y521mgJDMA2vkptki3985BA0eLJQRJa6M/bgmZZCM1Thx9giaXMAM 6Dku00I24ztQOcoubJNfEZOYa3kQPnmSIA1ulQCw5XxYaNJVnNjFmVUyWumKq4yz1hEW tPjA== X-Gm-Message-State: AOPr4FWJN0OzCSv36YU8IwBPVmoFI3XWBXLv7TTaKl8pokFR5xRkaYpLQ8obUdaSeK/aFMW/vzfDMsDXpCVYBA== MIME-Version: 1.0 X-Received: by 10.182.233.163 with SMTP id tx3mr5498594obc.36.1462404669042; Wed, 04 May 2016 16:31:09 -0700 (PDT) Received: by 10.60.52.145 with HTTP; Wed, 4 May 2016 16:31:08 -0700 (PDT) Date: Wed, 4 May 2016 18:31:08 -0500 Message-ID: Subject: Notes on slow kernel/ZFS memory leak resolved with FreeBSD-EN-16:08.zfs From: "Eric A. Borisch" To: "freebsd-fs@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 23:31:10 -0000 To elaborate on EN-16:08: this fixes a bug where any attempt to access a (1) previously mounted and (2) now destroyed snapshot leads to a small kernel memory leak on each attempt. These attempts can come in via NFS, from a local (potentially non-privileged) user, or even from within a jail, so long as the user/service would be able to enter into valid snapshots -- they don't need to be able to create snapshots themselves. We noticed it from repeated NFS attempts to mount an expired rolling snapshot; due to a slow but steady retry, the leak was clearly visible over long (multi-week) timescales. The leaked memory will show up labeled as 'mount' in vmstat -m, and is easy to verify as it will steadily grow with each failed attempt. - Eric - Eric From owner-freebsd-fs@freebsd.org Thu May 5 08:24:37 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B99ADB2D616 for ; Thu, 5 May 2016 08:24:37 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADE141396 for ; Thu, 5 May 2016 08:24:36 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.36] (izaro.sarenet.es [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPSA id B4F759DDD8C for ; Thu, 5 May 2016 10:14:29 +0200 (CEST) From: Borja Marcos Subject: ZFS and SSD, trim caused stalling Message-Id: <132CDFA3-0390-4208-B6D5-3F2AE49E4B47@sarenet.es> Date: Thu, 5 May 2016 10:14:29 +0200 To: freebsd-fs Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 08:24:37 -0000 Hello, Doing some tests with Intel P3500 NVMEs I have found a serious = performance problem caused by the TRIM operation.=20 Maybe it=E2=80=99s better not to use trim on these SSDs, I am not sure, = but anyway this reveals a serious performance problem which can happen with other SSDs. Actually I have seen a comparable behavior = at least with another SSD, although less serious. For example, trying with a 128 GB OCZ Vertex4, there was some stalling, = although this particular SSD trims at around 2 GB/s while it can sustain a write throughput of 200 MB/s until it reaches 50% capacity, = falling to around 100 MB/s. I know this is a very worst case benchmark, but operations like the = deletion of a large snapshot or a dataset could trigger similar problems. In order to do a gross check of the I/O performance of this system, I = created a raidz2 pool with 10 NVMEs. After creating it, I used Bonnie++. As a single bonnie instance is unable to = generate enough I/O activity, I actually ran=20 four in parallel. Doing a couple of tests, I noticed that the second time I launched four = Bonnies the writing activity was completely stalled. Repeeating a single test I noticed this (file OneBonnie.png): The Bonnies were writing for 30 minutes, the read/write test took around = 50 minutes, and the reading test took 10 minutes more or less. But after the Bonnie processes finished, the = deletion of the files took more or less 30 minutes of heavy trim activity.=20 Running two tests, one after another, showed something far more serious. = The second group of four Bonnies was stalled for around 15 minutes while there was heavy trim I/O = activity. And according to the service times reported by devstat, the stall didn=E2=80=99t happen in the disk I/O = subsystem. Looking at the activity between 8:30 and=20 8:45 it can be seen that the service time reported for the writing = operations is 0, which means that the write operations aren=E2=80=99t actually reaching the disk. (files TwoBonniesTput.png and = TwoBonniesTimes.png) ZFS itself is starving the whole vdev. Doing some silly operations such = a =E2=80=9Cls=E2=80=9D was a problem as well, the system performance was awful.=20 Apart from disabling TRIM there would be two solutions to this problem: 1) Somewhat deferring the TRIM operations. Of course it implies that the = block freeing work must be throttled, which can cause its own issues. 2) Skipping the TRIMs sometimes. Depending on the particular workload = and SSD model, TRIM can be almost mandatory or just a =E2=80=9Cnice to have=E2=80=9D feature. In a case like this, = deleting large files (four 512 GB files) has caused a very serious = impact. In this case TRIM has done more harm than good.=20 The selective TRIM skipping could be based just on the number of TRIM = requests pending on the vdev queues (past some threshold the TRIM requests would be discarded) or maybe the ZFS block = freeing routines would make a similar decision. I=E2=80=99m not sure where it=E2=80=99s better to implement this. A couple of sysctl variables could keep a counter of discarded TRIM = operations and total =E2=80=9Cnot trimmed=E2=80=9D bytes, making if = possible to know the impact of this measure. And this mechanism could be based = on some static threshold configured via a sysctl variable or, even better, ZFS could make a decision based on the queue depth. In case = write or read requests got an unacceptable service time, the system would invalidate the TRIM requests. What do you think? In some cases it=E2=80=99s clear that TRIM can do = more harm than good. I think that this measure can buy the best of both worlds: TRIMming when possible, during =E2=80=9Cnormal=E2=80=9D = I/O activity, and avoiding the troubles caused by it during exceptional activity (deletion of very large files/large number of files/large = snapshots/datasets). Borja. From owner-freebsd-fs@freebsd.org Thu May 5 08:59:50 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D0BDB2E04F for ; Thu, 5 May 2016 08:59:50 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu1176c.smtpx.saremail.com (cu1176c.smtpx.saremail.com [195.16.148.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 557E414E0 for ; Thu, 5 May 2016 08:59:49 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.36] (izaro.sarenet.es [192.148.167.11]) by proxypop02.sare.net (Postfix) with ESMTPSA id 71F079DC44C; Thu, 5 May 2016 10:50:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: ZFS and SSD, trim caused stalling From: Borja Marcos In-Reply-To: <132CDFA3-0390-4208-B6D5-3F2AE49E4B47@sarenet.es> Date: Thu, 5 May 2016 10:50:07 +0200 Cc: freebsd-fs Content-Transfer-Encoding: quoted-printable Message-Id: References: <132CDFA3-0390-4208-B6D5-3F2AE49E4B47@sarenet.es> To: Borja Marcos X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 08:59:50 -0000 > On 05 May 2016, at 10:14, Borja Marcos wrote: >=20 >=20 > What do you think? In some cases it=E2=80=99s clear that TRIM can do = more harm than good. I think that this measure can buy the best > of both worlds: TRIMming when possible, during =E2=80=9Cnormal=E2=80=9D = I/O activity, and avoiding the troubles caused by it during exceptional > activity (deletion of very large files/large number of files/large = snapshots/datasets). Sorry, I forgot that the mailing list removes attachments. These are the = graphs: http://frobula.crabdance.com:8001/publicfiles/OneBonnie.png http://frobula.crabdance.com:8001/publicfiles/TwoBonniesTimes.png http://frobula.crabdance.com:8001/publicfiles/TwoBonniesTput.png Botja. From owner-freebsd-fs@freebsd.org Thu May 5 13:19:08 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06584B2CE7A for ; Thu, 5 May 2016 13:19:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB4851E14 for ; Thu, 5 May 2016 13:19:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u45DJ7on027176 for ; Thu, 5 May 2016 13:19:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 207464] Panic when destroying ZFS snapshot on boot filesystem Date: Thu, 05 May 2016 13:19:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: hpowell@lighthouseinstruments.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 13:19:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207464 --- Comment #11 from Howard Powell --- Likely related to and fixed by this - testing as soon as I can patch. https://www.freebsd.org/security/advisories/FreeBSD-EN-16:08.zfs.asc --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu May 5 14:39:33 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B815AB2E9B2 for ; Thu, 5 May 2016 14:39:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 94B051F23 for ; Thu, 5 May 2016 14:39:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9418EB2E9B0; Thu, 5 May 2016 14:39:33 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93C2BB2E9AF for ; Thu, 5 May 2016 14:39:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65ED81F21 for ; Thu, 5 May 2016 14:39:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id u185so99348539iod.3 for ; Thu, 05 May 2016 07:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=sender:from:subject:date:message-id:to:mime-version; bh=Xp5PyWKsyWbs+3YmbYHOu6dCW6OcxOaLKueHkDQDoPY=; b=y2Zw0IqkNVLbsKNVl07k78HnGItlYiZ8rMD8/HP9m9KAad4YF612CmjVrDOhUVHLmM uE9e9byDrAeR05YeNIajOH8jxJgYme/DhYVgtWaZQtc/zufrfU9QoIAv+IZ+6EYCqqwx LNixQvqY8LcOC1L4jb3Q8pq5P/z6FnqGPTXRWsNuGsKIdIkgPn8Cb+zDKa2cBYTfI2K2 4T5a8ZLdhr8l3k1TcuBoZ3jqmfNvMAXXvDTl2guO4jXyImYwZPdqYpV5+zcVxphBs65N Y9bXMjaF4r7bNgbn8a1odjhU37W6yhYmpzFsaqVIZJ8WN27btkEbsDrhTSEqY4yyc8pg 74IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:subject:date:message-id:to :mime-version; bh=Xp5PyWKsyWbs+3YmbYHOu6dCW6OcxOaLKueHkDQDoPY=; b=iyzuX6touETmV8qh9RimsjLVj7EqrlD0h0+IE/4fXgAuOS4sTNT/1MpUyct92biV5S 5qU2SdABfUPJ4rgBxoaItZd+gbVCb6DT35aEOMYE+L2uKni6Ira6hrGGehb5QCc2fmSb OwQWCzIpVGoaOJo9bxCiWyfsMPoMML+4d388uqXvosLRWTIKTOGNePm0qCL4Aomfg87n By6pa7w8i4Q9PhAJSQXy3bMpzJLq+OybOwEDLZngweAalczYXH90rd5Y1MWL0SODHvG0 x+PP7V1bzmLEgDFB/J1orj9+sDYG8mqwKxTvWHkNtBT3cPHvmiJO8cSgL7gOadgkDzWd kxrw== X-Gm-Message-State: AOPr4FVVJtbuceepd49ylXht0v4jp/LoD3QaMLwoWfwgCHgnZ/6bYRHXPid8U5cIQhDn2A== X-Received: by 10.107.11.18 with SMTP id v18mr18985513ioi.184.1462459172669; Thu, 05 May 2016 07:39:32 -0700 (PDT) Received: from mac-wired.nflx.bsdimp.com ([50.253.99.174]) by smtp.gmail.com with ESMTPSA id r81sm4144273ioe.36.2016.05.05.07.39.31 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 May 2016 07:39:31 -0700 (PDT) Sender: Warner Losh From: Warner Losh X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_07680045-06FB-46B3-8F58-52B1F98FEAA7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: ZFS and SSD, trim caused stalling Date: Thu, 5 May 2016 08:39:30 -0600 Message-Id: <5E710EA5-C9B0-4521-85F1-3FE87555B0AF@bsdimp.com> To: fs@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 14:39:33 -0000 --Apple-Mail=_07680045-06FB-46B3-8F58-52B1F98FEAA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > What do you think? In some cases it=E2=80=99s clear that TRIM can do = more harm than good. I think it=E2=80=99s best we not overreact. This particular case is cause by the nvd driver, not the Intel P3500 = NVME drive. You need a solution (3): Fix the driver. Specifically, ZFS is pushing down a boatload of BIO_DELETE requests. In = ata/da land, these requests are queued up, then collapsed together as much as makes sense = (or is possible). This vastly helps performance (even with the extra sorting that I forced = to be in there that I need to fix before 11). The nvd driver needs to do the same thing. I=E2=80=99ve implemented, but can=E2=80=99t find in my hg queues, code = to do the deferral. After it gets the first trim, it starts a 100ms timer and pushes all the trims together to = the drive. This vastly unclogs the drive and makes things snappier. I never committed this code = upstream because I never committed it to the Netflix repo. We found better ways in our = application to avoid the thing that was generating a boatload of TRIMs. I also never made them = robust. I=E2=80=99d be extremely hesitant to tossing away TRIMs. They are = actually quite important for the FTL in the drive=E2=80=99s firmware to proper manage the NAND wear. = More free space always reduces write amplification. It tends to go as 1 / freespace, so simply = dropping them on the floor should be done with great reluctance. Warner --Apple-Mail=_07680045-06FB-46B3-8F58-52B1F98FEAA7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXK1siAAoJEGwc0Sh9sBEAwBIQAOboHkv2tGcS02W6H3py4h7u oNIcVqR/dnf1WN35TKLQbYJFsfFXqGxFVkVl6yP7bjDj10XlyCj3i0dHiA9wi83u F+Y49TxmKUoYtSpmrB/qFLCRZg/RTBPbMAtMkbs/GhuSiGLT8yZ72ZZpDjufuBwl QcCiekZGIPaaH3CRtnysmWuGM7DS54uFdeUGBiiYxirAI3JXDYFZwN0yIPIZI6EK uiH3sO7JmocLg9FJooHwTQ1uIWLH6ujNQibzX4zzv1S/x3qsTVs1WiniFFCuN1MV PJy1cG8cH+WZSFggoDf7qDp4/XJHKPHuUaCDDDYmzpf569ID+emcLvKz0wEkjHyK +psl53DMXBAHPXg9witTqoe/tcxfc4hw3SOsVtVs3wF10+GhIfDxyBc1ynCvfTs5 XPJApJYXYM07XCvk68Vh+2j8SJRgojIsycRNSFK51Qv/tm0m0ept5k+FL/GE+/sc L4+T8W84sdgM0dwuK3fPua2G2gNHjEoknmlMbdsrXJquCXACx64aGpNDnwvF0ZZZ T3iPH2sZfrzK3p+Gx6vHJI34NBAUv6wqDn/Mc6z/UZJyYCHrBKKrAregxxI7KXJa /s7FBeKS3Ysz4SKvmemV03reqDI0ep+nXC1y/4cZoiCakL7TNSk9rjOKmupvQG+9 bNSabmhoVEFeK0Cej4nF =50Cy -----END PGP SIGNATURE----- --Apple-Mail=_07680045-06FB-46B3-8F58-52B1F98FEAA7-- From owner-freebsd-fs@freebsd.org Thu May 5 14:39:59 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1312DB2EA0B for ; Thu, 5 May 2016 14:39:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE25B1FBA for ; Thu, 5 May 2016 14:39:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u45Edv7g033693 for ; Thu, 5 May 2016 14:39:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 207464] Panic when destroying ZFS snapshot on boot filesystem Date: Thu, 05 May 2016 14:39:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: karl@denninger.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 14:39:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207464 --- Comment #12 from karl@denninger.net --- I've put that (one-line) patch in and will see if I can trigger the panic again. Since it happens to me on a production system and I've been unable = to craft a test case that makes it happen repeatedly on my test machine it may= be a material amount of time before I can say it's fixed, given that the usual time-to-fail here is a week if I do not take interventions to prevent it. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu May 5 17:55:31 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B408B2EE7C for ; Thu, 5 May 2016 17:55:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C6841CC1 for ; Thu, 5 May 2016 17:55:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u45HtTkv026289 for ; Thu, 5 May 2016 17:55:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 207464] Panic when destroying ZFS snapshot on boot filesystem Date: Thu, 05 May 2016 17:55:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 17:55:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207464 Andriy Gapon changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open --- Comment #13 from Andriy Gapon --- Interesting... I can reproduce this problem but only if I repeat the instructions twice: $ zfs snapshot foo@panic $ ls -d /foo/.zfs/snapshot/panic $ zfs destroy foo@panic ... no problem here ... $ zfs snapshot foo@panic $ ls -d /foo/.zfs/snapshot/panic $ zfs destroy foo@panic ... now it panics ... This is using a UFS root filesystem and a freshly created pool. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu May 5 18:24:18 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5959B2EDD5 for ; Thu, 5 May 2016 18:24:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C8F414C4 for ; Thu, 5 May 2016 18:24:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u45IOHwP088415 for ; Thu, 5 May 2016 18:24:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 207464] Panic when destroying ZFS snapshot on boot filesystem Date: Thu, 05 May 2016 18:24:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: karl@denninger.net X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 18:24:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207464 --- Comment #14 from karl@denninger.net --- Andy, is that WITH the one-line patch in? If so, bummer. The pattern for me here on my production machines is that during backup the machine will panic, *always* during the root filesystem backup. The system is all-ZFS and the backups are done using zfs send, after creati= ng a snapshot (which rolls so you wind up with a duplicate of the existing file structure over time.) The system also uses timed snapshots that roll off so recovery of files is simple if they're accidentally deleted or modified wit= hout resorting to the backups. The panic is usually (but not always) preceded by a snapshot that is presen= t, cannot be destroyed, but *also* cannot be CD'd into. Once that condition exists the following is also true: 1. If you *reboot* the box the condition is cleared and all is well; the sy= stem will *not* panic in that instance. 2. If you attempt to zfs send a stream that *includes* the "orphan" snapshot the machine will panic in dounmount (identical behavior to the traces posted here) every time. 3. You cannot zfs destroy the "rogue" snapshot that is present in the direc= tory but cannot be cd'd into. These three things make it possible for my backup script to, most of the ti= me, detect the panic condition on the backup run *before* the one that blows up. What I've been unable to do, however, is reproduce a test case that reliably leaves the system in the pre-panic state. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu May 5 21:48:46 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D1D1B2F54C for ; Thu, 5 May 2016 21:48:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DEC41BBE for ; Thu, 5 May 2016 21:48:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u45Lmjsa075724 for ; Thu, 5 May 2016 21:48:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 207464] Panic when destroying ZFS snapshot on boot filesystem Date: Thu, 05 May 2016 21:48:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 21:48:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207464 --- Comment #15 from Andriy Gapon --- Created attachment 170024 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D170024&action= =3Dedit proposed patch for testing It seems that the code has a few bugs that _almost_ cancel out each other. Please try this patch that should eliminate those bugs. But the fix might uncover other bugs as the FreeBSD port of zfsctl / gfs co= de is rather hairy. So, treat with care. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu May 5 21:56:37 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF6E8B2F77D for ; Thu, 5 May 2016 21:56:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B014610CE for ; Thu, 5 May 2016 21:56:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u45LubWn092660 for ; Thu, 5 May 2016 21:56:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 207464] Panic when destroying ZFS snapshot on boot filesystem Date: Thu, 05 May 2016 21:56:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 21:56:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207464 --- Comment #16 from Andriy Gapon --- (In reply to karl from comment #14) I haven't tested the patch from the erratum, but it appears to be unrelated. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu May 5 22:08:39 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FD93B2F9EC for ; Thu, 5 May 2016 22:08:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80BCE1667 for ; Thu, 5 May 2016 22:08:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u45M8cAJ056783 for ; Thu, 5 May 2016 22:08:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 207464] Panic when destroying ZFS snapshot Date: Thu, 05 May 2016 22:08:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: dustinwenz@ebureau.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 22:08:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207464 dustinwenz@ebureau.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Panic when destroying ZFS |Panic when destroying ZFS |snapshot on boot filesystem |snapshot --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri May 6 21:13:43 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD74EB2D5B9 for ; Fri, 6 May 2016 21:13:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE4001353 for ; Fri, 6 May 2016 21:13:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u46LDf4M088608 for ; Fri, 6 May 2016 21:13:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 207464] Panic when destroying ZFS snapshot Date: Fri, 06 May 2016 21:13:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: hpowell@lighthouseinstruments.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 21:13:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207464 --- Comment #17 from Howard Powell --- I cannot get the proposed patch for testing to compile on a stock svn check= out of the 10.3 base head unless I modify VOP_UNLOCK(vp); to VOP_UNLOCK(vp, 0); in the opensolaris_vfs.c section. Compiling and testing now. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri May 6 21:15:02 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7D2FB2D65D for ; Fri, 6 May 2016 21:15:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98CF1143E for ; Fri, 6 May 2016 21:15:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u46LF2kd009559 for ; Fri, 6 May 2016 21:15:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 207464] Panic when destroying ZFS snapshot Date: Fri, 06 May 2016 21:15:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: hpowell@lighthouseinstruments.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 21:15:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207464 --- Comment #18 from Howard Powell --- (In reply to Howard Powell from comment #11) I can confirm that this seems to be unrelated. The kernel panic still occu= rs after updating to 10.3-RELEASE-p2 today. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri May 6 21:22:22 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2ABCEB2D9C7 for ; Fri, 6 May 2016 21:22:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BD401BF8 for ; Fri, 6 May 2016 21:22:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u46LMLQL048146 for ; Fri, 6 May 2016 21:22:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 207464] Panic when destroying ZFS snapshot Date: Fri, 06 May 2016 21:22:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: hpowell@lighthouseinstruments.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 21:22:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207464 --- Comment #19 from Howard Powell --- (In reply to Howard Powell from comment #17) Patched the 10.3-RELEASE kernel source and recompiled. A test case of creat= ing a snapshot, reading the snapshot, then destroying the snapshot 100 times finishes without a kernel panic. Looks promising. I'm beating the hell out of the new kernel now with 5 million create-read-destroy cycles to see what happens. Andriy - can you elaborate on "It seems that the code has a few bugs that _almost_ cancel out each other." - do you mean your proposed patch or the original code had bugs? ... waiting to push a mission critical machine into production until after = this is worked out. Thanks. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat May 7 14:55:34 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C91AB31339 for ; Sat, 7 May 2016 14:55:34 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 361931189 for ; Sat, 7 May 2016 14:55:34 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: by mailman.ysv.freebsd.org (Postfix) id 31711B31338; Sat, 7 May 2016 14:55:34 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 310A8B31337 for ; Sat, 7 May 2016 14:55:34 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from smtp.hungerhost.com (smtp.hungerhost.com [216.38.51.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03EFA1188 for ; Sat, 7 May 2016 14:55:33 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from cpe-67-245-246-80.nyc.res.rr.com ([67.245.246.80]:39779 helo=[10.0.1.146]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1az3dk-0006jE-HG for fs@freebsd.org; Sat, 07 May 2016 10:55:32 -0400 From: "George Neville-Neil" To: fs@freebsd.org Subject: Fwd: The Morning Paper: NOVA - A log-structured file system for hybrid volatile/non-volatile main memories Date: Sat, 07 May 2016 10:55:31 -0400 Message-ID: <2BE88161-D83A-4265-9EC3-C2F7F7033E93@neville-neil.com> References: <4188b6afbe9e5d43111fef4d4ae5e599a57.20160506051425@mail23.atl91.mcsv.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5234) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-Authenticated-Sender: vps.hungerhost.com: gnn@neville-neil.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 14:55:34 -0000 It's time for the project to start thinking about these issues IMHO. Best, George Forwarded message: > From: The Morning Paper > To: gnn@neville-neil.com > Subject: The Morning Paper: NOVA - A log-structured file system for = > hybrid volatile/non-volatile main memories > Date: Fri, 6 May 2016 05:14:40 +0000 > > The implications of combined DRAM and NVMM memory for file system = > design. > View this email in your browser = > (http://us9.campaign-archive1.com/?u=3D4188b6afbe9e5d43111fef4d4&id=3D2= 6178dba42&e=3Dae5e599a57) > This paper write-up is also available online at The Morning Paper. = > (http://blog.acolyer.org/2016/05/06/nova-a-log-structured-file-system-f= or-hybrid-volatilenon-volatile-main-memories) > > > ** the morning paper > ------------------------------------------------------------ > > > ** NOVA: A log-structured file system for hybrid volatile/non-volatile = > main memories > ------------------------------------------------------------ > > NOVA: A Log-structured file system for hybrid volatile/non-volatile = > main memories = > (http://cseweb.ucsd.edu/~swanson/papers/FAST2016NOVA.pdf) - Xu & = > Swanson 2016 > > Another paper looking at the design implications of mixed DRAM and = > NVMM systems (it=E2=80=99s the future!), this time in the context of fi= le = > systems. (NVMM =3D Non-volatile Main Memory). > > Hybrid DRAM/NVMM storage systems present a host of opportunities and = > challenges for system designers. These systems need to minimize = > software overhead if they are to fully exploit NVMM=E2=80=99s high = > performance and efficiently support more flexible access patterns, and = > at the same time they must provide the strong consistency guarantees = > that applications require and respect the limitations of emerging = > memories (e.g. limited program cycles). > > Why can=E2=80=99t we just take an existing file system and run it on to= p of = > a hybrid memory system? These file systems were built for the = > performance characteristics of disks (spinning or SSDs) - whereas NVMM = > and DRAM provide vastly improved performance. They where also built to = > rely on the consistency guarantees of disks (e.g. atomic sector = > updates), but memory provides different consistency guarantees from = > disks. One of the central issues here is the under-the-covers = > reordering of memory stores, and the need to explicitly flush data = > from CPU caches to compensate = > (https://blog.acolyer.org/2016/01/21/blurred-persistence/) . This can = > easily destroy any performance gains from NVMM if you=E2=80=99re not = > careful. > > To overcome all these limitations, we present the NOn-Volatile memory = > Accelerated (NOVA) log-structured file system. NOVA adapts = > conventional log-structured file system techniques to exploit the fast = > random access provided by hybrid memory systems. This allows NOVA to = > support massive concurrency, reduce log size, and minimize garbage = > collection costs while providing strong consistency guarantees for = > conventional file operations and mmap-based load/store accesses. > > All of this hard work pays off: =E2=80=9CWe find that NOVA is significa= ntly = > faster than existing file systems in a wide range of applications and = > outperforms file systems that provide the same data consistency = > guarantees by between 3.1x and 13.5x in write-intensive workloads.=E2=80= =9D > > There is a lot of detailed information about NOVA=E2=80=99s implementat= ion = > in the paper. Here I want to focus on the authors=E2=80=99 excellent = > discussion of what=E2=80=99s different about hybrid memory systems, and= how = > they approached the high-level design of NOVA as a consequence. > > > ** Challenges in designing for hybrid memory systems > ------------------------------------------------------------ > > Xu & Swanson outline three fundamental challenges when designing for = > hybrid memory systems: > 1. Realising the performance potential of the hardware > 2. Write reordering and its impact on consistency > 3. Providing atomicity for operations > > > ** Performance > ------------------------------------------------------------ > > The low latencies of NVMMs alters the trade-offs between hardware and = > software latency. In conventional storage systems, the latency of slow = > storage devices (e.g., disks) dominates access latency, so software = > efficiency is not critical. Previous work has shown that with fast = > NVMM, software costs can quickly dominate memory latency, squandering = > the performance that NVMMs could provide=E2=80=A6 > > It is possible to bypass the DRAM page cache and access NVMM directly = > using a technique called Direct Access (DAX), or eXecute In Place = > (XIP), avoiding extra copies between NVMM and DRAM in the storage = > stack. > > NOVA is a DAX file system, and we expect that all NVMM file systems = > will provide for these (or similar) features. > > > ** Write re-ordering > ------------------------------------------------------------ > > Modern processors and their caching hierarchies may reorder store = > operations to improve performance. The CPU=E2=80=99s memory consistency= = > protocol makes guarantees about the ordering of memory updates, but = > existing models (with the exception of research proposals [20, 46]) do = > not provide guarantees on when updates will reach NVMMs. As a result, = > a power failure may leave the data in an inconsistent state. > > It=E2=80=99s possible to explicitly flush caches and issue memory barri= ers = > to enforce write ordering. However, while an mfence will enforce order = > on memory operations before and after the barrier, it only guarantees = > all CPUs have the same view of the memory. It does not impose any = > constraints on the order of data writebacks to the NVMM. > > Intel has proposed new instructions to fix these problems, which = > include clflushopt, clwb and pcommit. =E2=80=9CNOVA is built with these= = > instructions in mind=E2=80=A6=E2=80=9D > > > ** Atomicity > ------------------------------------------------------------ > > Existing file systems use a variety of techniques like journaling, = > shadow paging, or log-structuring to provide atomicity guarantees. > > A journaling (WAL) system records all updates to a journal before = > applying them, and in the case of a power failure replays the journal = > to restore the system to a consistent state. Shadow paging is a = > copy-on-write mechanism in which a new copy of affected pages is = > written to storage on a write, before swapping out any references to = > the old pages for the new ones. Log-structured file systems (LFS) = > buffer random writes in memory and then convert them into larger = > sequential writes to the disk. This frequent a steady supply of = > contiguous free regions of disk, which in turn entails frequent = > cleaning and compacting of the log to reclaim space. > > RAMCloud (https://blog.acolyer.org/2016/01/18/ramcloud/) is an example = > of a DRAM based storage system that keeps all its data in DRAM to = > service reads, and keeps a persistent version on disk. It uses log = > structure for both DRAM and disk. > > > ** NOVA design principles > ------------------------------------------------------------ > > NOVA is a log-structured, POSIX file system that builds on the = > strengths of LFS and adapts them to take advantage of hybrid memory = > systems. Because it targets a different storage technology, NOVA looks = > very different from conventional log-structured file systems that are = > built to maximize disk bandwidth. > > Three observations influenced the design: > 1. Logs that support atomic updates are easy to implement in NVMM, but = > are not efficient for search operations (e.g. directory lookup and = > file random access). Data structures that support fast search (e.g. = > trees) are more difficult to implement correctly and efficiently in = > NVMM. > 2. The complexity of log cleaning in LFS comes from the need for = > contiguous free regions of storage. In NVMM however, random access is = > cheap and therefore we don=E2=80=99t need to write in contiguous region= s and = > hence don=E2=80=99t need such complex cleaning protocols. > 3. NVMMs support fast, highly concurrent random accesses, and = > therefore using multiple logs does not negatively impact performance. > > Based on this, NOVA: > * Keeps logs in NVMM, and indexes (radix trees) in DRAM. > * Gives each inode its own log, which allows concurrent updates across = > files without synchronization. During recovery, NOVA can replay = > multiple logs simultaneously. > * Uses logging and lightweight journaling for complex atomic updates. = > NOVA=E2=80=99s log-structure provides cheaper atomic updates than journ= aling = > or shadow paging. =E2=80=9CTo atomically write to a log, NOVA first app= ends = > data to the log, and then atomically updates the log tail to commit = > the updates, thus avoiding both the duplicate writes overhead of = > journaling file systems and the cascading update costs of shadow = > paging systems.=E2=80=9D > * Implements the log as a singly linked list! The locality benefits of = > sequential logs are less important in NVMM, so NOVA uses a linked list = > of 4KB NVMM pages. > > Allowing for non-sequential log storage provides three advantages. = > First, allocating log space is easy since NOVA does not need to = > allocate large, contiguous regions for the log. Second, NOVA can = > perform log cleaning at fine-grained page-size granularity. Third, = > reclaiming log pages that contain only stale entries requires just a = > few pointer assignments. > > * Finally, NOVA does not log file data. NOVA uses copy-on-write for = > modified pages, and appends metadata about the write to the log. > > The high-level layout of the NOVA data structures looks like this: > > NOVA=E2=80=99s atomicity comes from a combination of: > * 64-bit atomic updates - NOVA exploits processor support for 64-bit = > atomic writes to memory to directly modify metadata for some = > operations (e.g. a file=E2=80=99s atime for reads), and to commit updat= es to = > the log by updating the inode=E2=80=99s log tail pointer. > * Logging in the inode=E2=80=99s log to record operation that modify a = > single node. > * Lightweight journaling for directory operations that require changes = > to multiple nodes. > * Enforced write ordering by: (1) committing data and log entries to = > NVMM before updating the log tail; (2) committing journal data to NVMM = > before propagating updates; and (3) committing new versions of data = > pages to NVMM before recycling stale ones. If NOVA is running on a = > system that supports the new clflushopt=E2=80=99 clwb, and pcommit = > instructions it will use these to enforce the write ordering, = > otherwise it uses movntq, =E2=80=9Ca non-temporal move instruction that= = > bypasses the CPU cache hierarchy to perform direct writes to NVMM,=E2=80= =9D = > and a combination of clflush and mfence. > > > ** Evaluation > ------------------------------------------------------------ > > Figure 6 shows how NOVA file system operation latency compares to = > other file system across different NVMM configurations. > > Note that NOVA is more sensitive to NVMM performance than the other = > file systems because NOVA=E2=80=99s software overheads are lower, and s= o = > overall performance more directly reflects the underlying memory = > performance. > > Figure 7 shows how NOVA compares to other file systems across four = > Filebench workloads: a file server, web proxy, web server, and varmail = > (emulates an email server). > > Overall, NOVA achieves the best performance in almost all cases, and = > provides data consistency guarantees that are as strong or stronger = > than the other file systems. The performance advantages of NOVA are = > largest on write-intensive workloads with large numbers of files. > > http://twitter.com/intent/tweet?text=3DHow%20NVMM%20changes%20optimum%2= 0file%20system%20design.: = > http%3A%2F%2Fblog.acolyer.org%2F2016%2F05%2F06%2Fnova-a-log-structured-= file-system-for-hybrid-volatilenon-volatile-main-memories = > Tweet = > (http://twitter.com/intent/tweet?text=3DHow%20NVMM%20changes%20optimum%= 20file%20system%20design.: = > http%3A%2F%2Fblog.acolyer.org%2F2016%2F05%2F06%2Fnova-a-log-structured-= file-system-for-hybrid-volatilenon-volatile-main-memories) > This email was brought to you by #themorningpaper = > (http://blog.acolyer.org) : an interesting/influential/important paper = > from the world of CS every weekday morning, as selected by Adrian = > Colyer > > =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 > > Copyright =C2=A9 2016 One L and a Y Ltd, All rights reserved. > You are receiving this email because you opted into email delivery = > for your copy of The Morning Paper. > > Our mailing address is: > One L and a Y Ltd > Unit 5755 > PO Box 6945 > London, England W1A 6US > United Kingdom > ** unsubscribe from this list = > (http://acolyer.us9.list-manage.com/unsubscribe?u=3D4188b6afbe9e5d43111= fef4d4&id=3Dde5773de0c&e=3Dae5e599a57&c=3D26178dba42) > ** update subscription preferences = > (http://acolyer.us9.list-manage.com/profile?u=3D4188b6afbe9e5d43111fef4= d4&id=3Dde5773de0c&e=3Dae5e599a57) From owner-freebsd-fs@freebsd.org Sat May 7 16:45:20 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 135B3B31AA9 for ; Sat, 7 May 2016 16:45:20 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 01B9C1BA7 for ; Sat, 7 May 2016 16:45:20 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id F19F7B31AA8; Sat, 7 May 2016 16:45:19 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF081B31AA7 for ; Sat, 7 May 2016 16:45:19 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id AAA781BA6 for ; Sat, 7 May 2016 16:45:19 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 4CE364FB03; Sat, 7 May 2016 16:38:24 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u47GcLq0059878; Sat, 7 May 2016 16:38:22 GMT (envelope-from phk@phk.freebsd.dk) To: "George Neville-Neil" cc: fs@freebsd.org Subject: Re: Fwd: The Morning Paper: NOVA - A log-structured file system for hybrid volatile/non-volatile main memories In-reply-to: <2BE88161-D83A-4265-9EC3-C2F7F7033E93@neville-neil.com> From: "Poul-Henning Kamp" References: <4188b6afbe9e5d43111fef4d4ae5e599a57.20160506051425@mail23.atl91.mcsv.net> <2BE88161-D83A-4265-9EC3-C2F7F7033E93@neville-neil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <59876.1462639101.1@critter.freebsd.dk> Date: Sat, 07 May 2016 16:38:21 +0000 Message-ID: <59877.1462639101@critter.freebsd.dk> X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 16:45:20 -0000 That's a pretty obvious idea, all things considered, but not necessarily a good idea and certainly not the best idea. Hybrid "disk with SSD cache" is a transitionary phenomena, it's probably not going to be relevant in five years, which means that it is almost already too late to develop a new filesystem for it: By the time the code is trustworthy, nobody will need it any more. That is not to say that there are no relevant improvements to make. Many years ago we removed the rotational optimizations in FFS in response to zoned drives, and given the properties of SSDs it is no longer evident that journaling, softupdates or even supergroups are good ideas anymore. The design-choices to make metadata updates single-sector modifications should be revisited as well. While LFS seems an obvious storage strategy for SSDs, it's surplus to requirements because SSD devices already contains a LFS. Only they call files "a logical sector (extent)" and the LFS itself a "Flash Adaptation Layer". LFS also has some well documented drawbacks, in particular WRT cleaning, and the optimization that is a tradeoff for are utterly pointless on media effectively without access time. It would probably be smarter to focus on reducing the the number of, and increasing the size of media I/O transactions, with a side order of general scalability, so that small files have small metadata and bigger files trade metadatasize for performance. There is also an interesting space between per-partition and per-inode keying of encryption which is ripe for study. The double or even triple work overlap between todays filesystems and the FALs in SSDs could be avoided if a more expressive set of verbs than Read/Write/Erase(=TRIM) were exported upwards (expose the extents as "inodes" ?) but given the patent-minefield and the heavy-duty NIH-attitudes, that is probably not going to happen. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-fs@freebsd.org Sat May 7 23:16:49 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97824B321EC for ; Sat, 7 May 2016 23:16:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 87E1B1C7B for ; Sat, 7 May 2016 23:16:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u47NGnaa076790 for ; Sat, 7 May 2016 23:16:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 208691] "panic: ffs_valloc: dup alloc" as soon as UFS root partition is mounted Date: Sat, 07 May 2016 23:16:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mckusick@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 23:16:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208691 Kirk McKusick changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Not A Bug --- Comment #4 from Kirk McKusick --- I am closing this bug as it is triggered by disks running in an unreliable mode. As such there is no change called for in the software, though one can legitimately argue that the default should be to configure disks to run with `write cache disabled' so that they will be reliable. FreeBSD ran for a whi= le with this default, but for many disks the performance was abysmal, so the default reverted back to unreliable. Most disks support tag queuing today w= hich does not suffer poor performance from `write cache disabled', so perhaps it= is time to revisit this default. But that is not a topic for this report. --=20 You are receiving this mail because: You are the assignee for the bug.=