From owner-freebsd-fs@freebsd.org Sun Sep 13 12:55:14 2015 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 548EEA036E6 for ; Sun, 13 Sep 2015 12:55:14 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 E930F142F for ; Sun, 13 Sep 2015 12:55:13 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by wiclk2 with SMTP id lk2so110167633wic.0 for ; Sun, 13 Sep 2015 05:55:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=BfRi7nbQcMqf8pd12rSgYg77rOFeAN7b7c9+2ytgK7Y=; b=HMLK4oDO+wrRpLxVEQbqz/NvoFvx/xcqeXB3BiVjnYf4Qr3gxE6unRzGZnbmJIQD7P i+0abeowrLYEAfUk4Ffcv9UFsezDnFMkWYTUeX6LF1uhWHhv/HzpKwkST4Uyf12C5QCr 919Tob+I/fs617JkX8r09fxxWvLGoIAxJbnMStmilu7/YeaxCJahae0DFMxPmXtdvE0c hgo9nQkMdzbMnQaf/r0/jHkC3WaPeuMR5xcesnXQaOV69E77O6a4E2DAFZK52tYebycu zU7Os2gikp2WpPFzoFzC955Jq+aW81DBvudbM+hiVML/5tQaD/IexhRSbouZPRHTl75J N2mQ== X-Gm-Message-State: ALoCoQnAOHntvavjugCwgpDgnHO43aG121r4g/bx+xWvATZAQOt0VT1RMgKKyKL67pCYXpJwWr3I X-Received: by 10.194.71.107 with SMTP id t11mr18065966wju.142.1442148911613; Sun, 13 Sep 2015 05:55:11 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by smtp.gmail.com with ESMTPSA id t7sm1391504wib.1.2015.09.13.05.55.10 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Sep 2015 05:55:10 -0700 (PDT) From: Steven Hartland X-Google-Original-From: Steven Hartland Subject: Re: zfs_trim_enabled destroys zio_free() performance To: freebsd-fs@freebsd.org References: Message-ID: <55F57228.4090500@freebsd.org> Date: Sun, 13 Sep 2015 13:55:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 12:55:14 -0000 On 11/09/2015 17:07, Matthew Ahrens wrote: > I discovered that when destroying a ZFS snapshot, we can end up using > several seconds of CPU via this stack trace: > > kernel`spinlock_exit+0x2d > kernel`taskqueue_enqueue+0x12c > zfs.ko`zio_issue_async+0x7c > zfs.ko`zio_execute+0x162 > zfs.ko`dsl_scan_free_block_cb+0x15f > zfs.ko`bpobj_iterate_impl+0x25d > zfs.ko`bpobj_iterate_impl+0x46e > zfs.ko`dsl_scan_sync+0x152 > zfs.ko`spa_sync+0x5c1 > zfs.ko`txg_sync_thread+0x3a6 > kernel`fork_exit+0x9a > kernel`0xffffffff80d0acbe > 6558 ms > > This is not good for performance since, in addition to the CPU cost, it > doesn't allow the sync thread to do anything else, and this is observable > as periods where we don't do any write i/o to disk for several seconds. > > The problem is that when zfs_trim_enabled is set (which it is by default), > zio_free_sync() always sets ZIO_STAGE_ISSUE_ASYNC, causing the free to be > dispatched to a taskq. Since each task completes very quickly, there is a > large locking and context switching overhead -- we would be better off just > processing the free in the caller's context. > > I'm not sure exactly why we need to go async when trim is enabled, but it > seems like at least we should not bother going async if trim is not > actually being used (e.g. with an all-spinning-disk pool). It would also > be worth investigating not going async even when trim is useful (e.g. on > SSD-based pools). > > Here is the relevant code: > > zio_free_sync(): > if (zfs_trim_enabled) > stage |= ZIO_STAGE_ISSUE_ASYNC | ZIO_STAGE_VDEV_IO_START | > ZIO_STAGE_VDEV_IO_ASSESS; > /* > * GANG and DEDUP blocks can induce a read (for the gang block > header, > * or the DDT), so issue them asynchronously so that this thread is > * not tied up. > */ > else if (BP_IS_GANG(bp) || BP_GET_DEDUP(bp)) > stage |= ZIO_STAGE_ISSUE_ASYNC; TRIM requests are queued, combined and only actioned after time in the TRIM thread as they are quite expensive which why I believe it was thought async was required, however given all this will do is trigger a call to trim_map_free for leaf vdev's which will be either: 1. A no-op if vdev_notrim is set (spinning rust) 2. An insert into the trim AVL The processing of the zio should always be quick I don't see why we couldn't execute it sync. I've set a test going on my head box removing ZIO_STAGE_ISSUE_ASYNC to see if I get any strange behaviour. Regards Steve From owner-freebsd-fs@freebsd.org Sun Sep 13 13:04:02 2015 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 EF65CA03ACF for ; Sun, 13 Sep 2015 13:04:01 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 8E6461B18 for ; Sun, 13 Sep 2015 13:04:01 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by wiclk2 with SMTP id lk2so110309296wic.0 for ; Sun, 13 Sep 2015 06:03:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=uZlz0eI5sXUjhKewweK6fqri5U10/bKH6elzoU06kFM=; b=CMSsWv5peS0FA7VSfIYGpIJaAHjZj00l+tJ6VR/4rormdhHDAAL7nB0Txe/pW4z+Yz 3La+TVePCl/MvJzFWgTiDbT43XHnI9D1o645R1vEKCtnqvEt/AT6bTaK93z3BhmlJpse iFO+MY/g8mCWL7ArPb6e4WAxwBlL9Gi69D7/gZndIvOzhes9NUeGoBh16EI1zxn9dJ2P R2deqI0KrHD6o2MGMf72FfMgmdLwnEgdIbIxP0xRA1wUP6qCrOuRNJ3nqdU/7KA2olFO fCn2/EAutd+j2QVtEtXDzAl15+ki+MVWfUy4FaWtT2nu9eFpsgX1gAfZue3o5mj//ebv WqKQ== X-Gm-Message-State: ALoCoQn4J8i+SkQFaz2n8MiLRr+8XMJkyW968HJDpZg1yDyNHA1SG9IAnHJnEQhNHmWWOKNbjmQy X-Received: by 10.180.92.138 with SMTP id cm10mr15506136wib.33.1442149439660; Sun, 13 Sep 2015 06:03:59 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by smtp.gmail.com with ESMTPSA id jw9sm10257051wjb.28.2015.09.13.06.03.58 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Sep 2015 06:03:59 -0700 (PDT) Subject: Re: zfs_trim_enabled destroys zio_free() performance To: freebsd-fs@freebsd.org References: <55F308B7.3020302@FreeBSD.org> From: Steven Hartland Message-ID: <55F57439.8060000@multiplay.co.uk> Date: Sun, 13 Sep 2015 14:03:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F308B7.3020302@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 13:04:02 -0000 Do you remember if this was this causing a deadlock or something similar that's easy to provoke? Regards Steve On 11/09/2015 18:00, Alexander Motin wrote: > Hi. > > The code in question was added by me at r253992. Commit message tells it > was made to decouple locks. I don't remember much more details, but may > be it can be redone somehow else. > > On 11.09.2015 19:07, Matthew Ahrens wrote: >> I discovered that when destroying a ZFS snapshot, we can end up using >> several seconds of CPU via this stack trace: >> >> kernel`spinlock_exit+0x2d >> kernel`taskqueue_enqueue+0x12c >> zfs.ko`zio_issue_async+0x7c >> zfs.ko`zio_execute+0x162 >> zfs.ko`dsl_scan_free_block_cb+0x15f >> zfs.ko`bpobj_iterate_impl+0x25d >> zfs.ko`bpobj_iterate_impl+0x46e >> zfs.ko`dsl_scan_sync+0x152 >> zfs.ko`spa_sync+0x5c1 >> zfs.ko`txg_sync_thread+0x3a6 >> kernel`fork_exit+0x9a >> kernel`0xffffffff80d0acbe >> 6558 ms >> >> This is not good for performance since, in addition to the CPU cost, it >> doesn't allow the sync thread to do anything else, and this is >> observable as periods where we don't do any write i/o to disk for >> several seconds. >> >> The problem is that when zfs_trim_enabled is set (which it is by >> default), zio_free_sync() always sets ZIO_STAGE_ISSUE_ASYNC, causing the >> free to be dispatched to a taskq. Since each task completes very >> quickly, there is a large locking and context switching overhead -- we >> would be better off just processing the free in the caller's context. >> >> I'm not sure exactly why we need to go async when trim is enabled, but >> it seems like at least we should not bother going async if trim is not >> actually being used (e.g. with an all-spinning-disk pool). It would >> also be worth investigating not going async even when trim is useful >> (e.g. on SSD-based pools). >> >> Here is the relevant code: >> >> zio_free_sync(): >> if (zfs_trim_enabled) >> stage |= ZIO_STAGE_ISSUE_ASYNC | ZIO_STAGE_VDEV_IO_START | >> ZIO_STAGE_VDEV_IO_ASSESS; >> /* >> * GANG and DEDUP blocks can induce a read (for the gang block >> header, >> * or the DDT), so issue them asynchronously so that this thread is >> * not tied up. >> */ >> else if (BP_IS_GANG(bp) || BP_GET_DEDUP(bp)) >> stage |= ZIO_STAGE_ISSUE_ASYNC; >> >> --matt > From owner-freebsd-fs@freebsd.org Sun Sep 13 21:00:27 2015 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 A89D2A0322A for ; Sun, 13 Sep 2015 21:00:27 +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 83B031336 for ; Sun, 13 Sep 2015 21:00:27 +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 t8DL0R1D013719 for ; Sun, 13 Sep 2015 21:00:27 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201509132100.t8DL0R1D013719@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 X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 13 Sep 2015 21:00:27 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 21:00:27 -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 ------------+-----------+--------------------------------------------------- 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 3 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Sun Sep 13 23:10:14 2015 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 EFB63A04881 for ; Sun, 13 Sep 2015 23:10:14 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 4406D1B20 for ; Sun, 13 Sep 2015 23:10:13 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 12381 invoked by uid 907); 13 Sep 2015 23:03:31 -0000 Received: from eth222.nsw.adsl.internode.on.net (HELO [192.168.1.101]) (150.101.196.221) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA; Mon, 14 Sep 2015 09:03:31 +1000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: L2ARC and pool corruption From: Jan Mikkelsen In-Reply-To: Date: Mon, 14 Sep 2015 09:03:29 +1000 Cc: Mark Saad , "freebsd-fs@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <09E1F540-C9E6-4193-851E-5F935D97763F@transactionware.com> References: <76AD038E-4D72-48BB-8A3B-BD9BD76F9350@longcount.org> To: Tom Curry X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 23:10:15 -0000 > On 13 Sep 2015, at 01:21, Tom Curry wrote: >=20 > On Sat, Sep 12, 2015 at 7:19 AM, Mark Saad = wrote: >=20 >> All >> I forgot to include my question . In any case Ryan and I were = talking >> about this issue at work and I was wondering if and how this issue = would >> effect the FreeBSD implementation of zfs . I didn't see any commits = that >> appear to address this . >>=20 >> --- >> Mark Saad | nonesuch@longcount.org >>=20 >>=20 > = https://github.com/freebsd/freebsd/commit/0ab19d08a4167c4e486420d8ea4ec596= 8cbc4f42 >=20 > Looks like it was merged into head 5 hours ago. Does this update need to be applied to stable/10 or 10.2 systems as = well? Thanks Jan Mikkelsen. From owner-freebsd-fs@freebsd.org Mon Sep 14 00:49:01 2015 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 9E523A03E38 for ; Mon, 14 Sep 2015 00:49:01 +0000 (UTC) (envelope-from thomasrcurry@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 6EDA910F7 for ; Mon, 14 Sep 2015 00:49:01 +0000 (UTC) (envelope-from thomasrcurry@gmail.com) Received: by ioii196 with SMTP id i196so149770151ioi.3 for ; Sun, 13 Sep 2015 17:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i8PHgJxjRof96LKX6Lh6VYeFlkZD9C0n6YFilsggTdk=; b=lOUppxg9L3DMT6gJXOLE9liGVfIG/WACx7cdrBjmKoVWuVEklhYv6N0cojZQMp9IRP nez4kKnzX9i8TPzT6uCWCHWmrJZCFkrpNyy+KkxdJ1r0gDoYRMChYHP14s9ZKmua4f2X bc780frpdjyHPYjFCOiVArVkCNew/p6KJuQt4OKWOXYRAvLeL+JgOMzdi8Wxf9x05ROn kWoZOsEdtmNhXDhExbKe3VqPdxMecQas07WwcAvpzc8lQLHNoRbg2gL1ehV9TSbWMPCV MF7xCq9zOCebFstHpD8m4uWwBqg1L7EkbpXjzkBcGQREaYIgGwnRGXTdp7UNYQ2ZUedG 8niQ== MIME-Version: 1.0 X-Received: by 10.107.16.80 with SMTP id y77mr19195913ioi.183.1442191740801; Sun, 13 Sep 2015 17:49:00 -0700 (PDT) Received: by 10.107.4.72 with HTTP; Sun, 13 Sep 2015 17:49:00 -0700 (PDT) In-Reply-To: <09E1F540-C9E6-4193-851E-5F935D97763F@transactionware.com> References: <76AD038E-4D72-48BB-8A3B-BD9BD76F9350@longcount.org> <09E1F540-C9E6-4193-851E-5F935D97763F@transactionware.com> Date: Sun, 13 Sep 2015 20:49:00 -0400 Message-ID: Subject: Re: L2ARC and pool corruption From: Tom Curry To: Jan Mikkelsen Cc: Mark Saad , "freebsd-fs@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 00:49:01 -0000 On Sun, Sep 13, 2015 at 7:03 PM, Jan Mikkelsen wrote: > > > On 13 Sep 2015, at 01:21, Tom Curry wrote: > > > > On Sat, Sep 12, 2015 at 7:19 AM, Mark Saad > wrote: > > > >> All > >> I forgot to include my question . In any case Ryan and I were talking > >> about this issue at work and I was wondering if and how this issue would > >> effect the FreeBSD implementation of zfs . I didn't see any commits that > >> appear to address this . > >> > >> --- > >> Mark Saad | nonesuch@longcount.org > >> > >> > > > https://github.com/freebsd/freebsd/commit/0ab19d08a4167c4e486420d8ea4ec5968cbc4f42 > > > > Looks like it was merged into head 5 hours ago. > > Does this update need to be applied to stable/10 or 10.2 systems as well? > > Thanks > > Jan Mikkelsen. > > When I looked yesterday it had only been applied to head. It seems like a simple enough patch for other trees. From owner-freebsd-fs@freebsd.org Mon Sep 14 00:59:35 2015 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 51C3DA03388 for ; Mon, 14 Sep 2015 00:59:35 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id C2D5E145B for ; Mon, 14 Sep 2015 00:59:33 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 38039 invoked by uid 907); 14 Sep 2015 00:59:30 -0000 Received: from eth222.nsw.adsl.internode.on.net (HELO [192.168.1.101]) (150.101.196.221) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA; Mon, 14 Sep 2015 10:59:30 +1000 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: L2ARC and pool corruption From: Jan Mikkelsen In-Reply-To: Date: Mon, 14 Sep 2015 10:59:30 +1000 Cc: Mark Saad , "freebsd-fs@freebsd.org" Message-Id: <39E7A9FD-38BA-48E4-9718-C32AB4712C31@transactionware.com> References: <76AD038E-4D72-48BB-8A3B-BD9BD76F9350@longcount.org> <09E1F540-C9E6-4193-851E-5F935D97763F@transactionware.com> To: Tom Curry X-Mailer: Apple Mail (2.2104) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 00:59:35 -0000 > On 14 Sep 2015, at 10:49, Tom Curry wrote: >=20 >=20 >=20 > On Sun, Sep 13, 2015 at 7:03 PM, Jan Mikkelsen = > wrote: >=20 > > On 13 Sep 2015, at 01:21, Tom Curry > wrote: > > > > On Sat, Sep 12, 2015 at 7:19 AM, Mark Saad > wrote: > > > >> All > >> I forgot to include my question . In any case Ryan and I were = talking > >> about this issue at work and I was wondering if and how this issue = would > >> effect the FreeBSD implementation of zfs . I didn't see any commits = that > >> appear to address this . > >> > >> --- > >> Mark Saad | nonesuch@longcount.org > >> > >> > > = https://github.com/freebsd/freebsd/commit/0ab19d08a4167c4e486420d8ea4ec596= 8cbc4f42 = > > > > Looks like it was merged into head 5 hours ago. >=20 > Does this update need to be applied to stable/10 or 10.2 systems as = well? >=20 > Thanks >=20 > Jan Mikkelsen. >=20 >=20 > When I looked yesterday it had only been applied to head. It seems = like a simple enough patch for other trees. OK, so it=E2=80=99s a necessary patch for other trees? I=E2=80=99ll = apply it on our local copy, but for data corruption issues like this it = seems like an MFC or a patch to a release branch would be good. Regards, Jan. From owner-freebsd-fs@freebsd.org Mon Sep 14 05:27:28 2015 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 90600A03D54 for ; Mon, 14 Sep 2015 05:27:28 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id EF4F011D6 for ; Mon, 14 Sep 2015 05:27:26 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 84582 invoked by uid 907); 14 Sep 2015 05:27:22 -0000 Received: from Unknown (HELO jmmacpro.tmst.com.au) (203.14.245.130) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA; Mon, 14 Sep 2015 15:27:22 +1000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: L2ARC and pool corruption From: Jan Mikkelsen In-Reply-To: <39E7A9FD-38BA-48E4-9718-C32AB4712C31@transactionware.com> Date: Mon, 14 Sep 2015 15:27:21 +1000 Cc: "freebsd-fs@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2A71C2D2-78DC-4211-B99A-72B41EDEAEC3@transactionware.com> References: <76AD038E-4D72-48BB-8A3B-BD9BD76F9350@longcount.org> <09E1F540-C9E6-4193-851E-5F935D97763F@transactionware.com> <39E7A9FD-38BA-48E4-9718-C32AB4712C31@transactionware.com> To: Tom Curry X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 05:27:28 -0000 > On 14 Sep 2015, at 10:59, Jan Mikkelsen = wrote: >=20 >=20 >> On 14 Sep 2015, at 10:49, Tom Curry wrote: >>=20 >>=20 >>=20 >> On Sun, Sep 13, 2015 at 7:03 PM, Jan Mikkelsen = > wrote: >>=20 >>> On 13 Sep 2015, at 01:21, Tom Curry > wrote: >>>=20 >>> On Sat, Sep 12, 2015 at 7:19 AM, Mark Saad > wrote: >>>=20 >>>> All >>>> I forgot to include my question . In any case Ryan and I were = talking >>>> about this issue at work and I was wondering if and how this issue = would >>>> effect the FreeBSD implementation of zfs . I didn't see any commits = that >>>> appear to address this . >>>>=20 >>>> --- >>>> Mark Saad | nonesuch@longcount.org >>>>=20 >>>>=20 >>> = https://github.com/freebsd/freebsd/commit/0ab19d08a4167c4e486420d8ea4ec596= 8cbc4f42 = >>>=20 >>> Looks like it was merged into head 5 hours ago. >>=20 >> Does this update need to be applied to stable/10 or 10.2 systems as = well? >>=20 >> Thanks >>=20 >> Jan Mikkelsen. >>=20 >>=20 >> When I looked yesterday it had only been applied to head. It seems = like a simple enough patch for other trees. >=20 >=20 > OK, so it=E2=80=99s a necessary patch for other trees? I=E2=80=99ll = apply it on our local copy, but for data corruption issues like this it = seems like an MFC or a patch to a release branch would be good. Replying to myself after a bit more investigation =E2=80=94 this patch = fixes a problem introduced in r287699, which is only in head. As far as = I can see no action is required for stable/10. From owner-freebsd-fs@freebsd.org Mon Sep 14 16:22:30 2015 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 CB3F7A03B16 for ; Mon, 14 Sep 2015 16:22:30 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 99E7E11F1 for ; Mon, 14 Sep 2015 16:22:30 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: by igbkq10 with SMTP id kq10so91073038igb.0 for ; Mon, 14 Sep 2015 09:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=bjutrcd9BC+OGTo9qXfM32PR1PviaNP/tT3SBGDlt4Q=; b=V78S3gBACmdbii8rziraEKTvQjWEc0oO7DVaVI3IuBCi5vo2NaUr/oB/q5dj25Ska2 PoIx99KaRrNwkxIoZhZ3g32Mxhw5XvVoQl07JSqeHKj5L9tYP0/nZx1Vf3y2g29MO2HU yaqxyG6A103sQYCty9H9VGpcYqR7WYo4Gffd4= 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:cc :content-type; bh=bjutrcd9BC+OGTo9qXfM32PR1PviaNP/tT3SBGDlt4Q=; b=SPmsLdW7Ha2MZvvoImxi/yTms/XKXohZJDtC4YMCeC9L+Bhhb2KSYpr2xBCHgVI/0c 7jcYTYkbjlAItBFMdSsaCJVpYCzFfr5xEpSYPE5cJI9Y4LNPA6WODloAN1oGPuG/q1gY dOJXJLdLjft6h70L9ysvCpIaBW2OJwFL62vCUarCCYfx3uf5TLsT0uJPss+2JHHyRu+t I7WIX1eoB4zT+ks8W3iLGIJolMdiSOk77F4lFeIVLQ2/q2NrPlb8KYmcr+OybRUDRb0Z xvLGLP1on6RuvdktqyGiXMnfto4mXSq01qH5VHmZm5JvYxXRVp4q4k+Z0gVh3LCSr3EP KANQ== X-Gm-Message-State: ALoCoQkAZwSeNzemVrQxuGfurmmNvfye+Ci+5qw0CFSlJhuXXAWecg/olaTzEit3TjY4MtKf0Deo MIME-Version: 1.0 X-Received: by 10.50.78.41 with SMTP id y9mr18818156igw.72.1442247749178; Mon, 14 Sep 2015 09:22:29 -0700 (PDT) Received: by 10.36.86.208 with HTTP; Mon, 14 Sep 2015 09:22:29 -0700 (PDT) Date: Mon, 14 Sep 2015 09:22:29 -0700 Message-ID: Subject: OpenZFS Developer Summit speakers announced From: Matthew Ahrens To: developer , illumos-zfs , freebsd-fs , zfs-discuss Cc: Anastasiya Dubrovina Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 16:22:31 -0000 I am pleased to announce a great lineup of speakers at the 2015 OpenZFS Developer Summit! Please join us and register on Eventbrite by September 25th to ensure that we have a T-shirt in your size. Registration will remain open until space is filled, but we have to order shirts on the 25th. The shirts are similar to last year's awesome shirts but feature a different iconic work of San Francisco civil engineering, so you don't want to miss out :-) TitleSpeakerCompanyKeynoteMatt AhrensDelphix OpenZFS Success StoriesTarkan ManerNexenta Parity Declustered RAID-Z/MirrorIsaac HuangIntel Persistent L2ARCSaso KiselkovNexenta Dedup CeilingSaso KiselkovNexenta The Birth of ZFSJeff BonwickDSSD , EMC Compressed ARCGeorge WilsonDelphix Live Migration with ZmotionFrancois LesageOVH ZtourDon BradyIntel Writeback CacheAlex AizmanNexenta Discontiguous Caching with ABDDavid Chen OSNexus Sandboxing OpenZFS on LinuxAlbert LeeOmniTI ZFS Internals OverviewKirk McKusickIndependentZFS Send and ReceivePaul DagnelieDelphix Compressed Send and ReceiveDan KimmelDelphix All the info is on the website: http://open-zfs.org/wiki/OpenZFS_Developer_Summit_2015--matt From owner-freebsd-fs@freebsd.org Mon Sep 14 23:42:24 2015 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 8C63CA03C14 for ; Mon, 14 Sep 2015 23:42:24 +0000 (UTC) (envelope-from schittenden@groupon.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 244F11276 for ; Mon, 14 Sep 2015 23:42:23 +0000 (UTC) (envelope-from schittenden@groupon.com) Received: by wiclk2 with SMTP id lk2so6028340wic.0 for ; Mon, 14 Sep 2015 16:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=groupon.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=s51Q6KQRIInEbUG3S+45xIxKkPaLn8jcuzibMPEW69I=; b=QbC3goleAzAq6DfiYDB8iWwe6AF+8lEp3L5D9+4hH2vn5ebPCzhp+p6yXrF4qB5XmD w9t+BvzaIGWdI7IjZ4OVDh7yLmw6WGSPMIR5VrlOU8R6z5ipnjX6PJxBBXKeHV1G0saq d06aS9vbgBbHKtb2tJP/RdXb/2gbfHdwIOus4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=s51Q6KQRIInEbUG3S+45xIxKkPaLn8jcuzibMPEW69I=; b=TE5DKJTOLSWp+q3mGXYxxSmvYgEkod3BW8+qpYgnvOw+EKlNaw/xncFjiFojEv4/B7 yapBd5AsoXGwl83EnW08+VmRG29xp3K69gROHBkcjqx3bbmXyoPBvd6TiuTm5evbzHak Ihi90+0PXiVWdvm3E2Ax440R9MP1bMEJMCvLoqohV+6IJMQOA24HBSvo9ib2Sq0Hue1+ ngUEmFO6MnRCl1xAoa2OHmGvp5Ls4AykhwxzuTeItvTm7GR09aNhQlT9QyOgdPXJRPvl TE5VDbWUlua6kAedgMg4tHB4xw0S7C14TqUZEwtxGxTJGQuLWh5mQsEJWIsVDy7dZd21 sumw== X-Gm-Message-State: ALoCoQk49tppsrqhk3yqlzJntaqhe7rJuttRyQsjru+erXQBEmyXuTET1O9p0DUwv1ASh97sfCXz X-Received: by 10.194.173.72 with SMTP id bi8mr33635194wjc.100.1442274142300; Mon, 14 Sep 2015 16:42:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.116.230 with HTTP; Mon, 14 Sep 2015 16:41:42 -0700 (PDT) In-Reply-To: <55F57439.8060000@multiplay.co.uk> References: <55F308B7.3020302@FreeBSD.org> <55F57439.8060000@multiplay.co.uk> From: Sean Chittenden Date: Mon, 14 Sep 2015 16:41:42 -0700 Message-ID: Subject: Re: zfs_trim_enabled destroys zio_free() performance To: Steven Hartland Cc: FreeBSD Filesystems , Matthew Ahrens Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 23:42:24 -0000 Random =E2=80=8Bindustry note , we've had issues with trim-enabled hosts where =E2=80=8Bdeleting a moderate sized dataset (~1TB) would cause the box to tr= ip over the deadman timer =E2=80=8B. When the host comes back up it almost immediately panics again = because the trim commands will be reissued again causing the box to panic in a loop. Disabling TRIM breaks this cycle. At the very least, getting trim to obey a different timer would useful. -sc=E2=80=8B # panic: I/O to pool 'tank' appears to be hung on vdev guid > 1181753144268412659 at '/dev/da0p1'. > cpuid =3D 13 > KDB: stack backtrace: > #0 0xffffffff805df950 at kdb_backtrace+0x60 > #1 0xffffffff805a355d at panic+0x17d > #2 0xffffffff81034db3 at vdev_deadman+0x123 > #3 0xffffffff81034cc0 at vdev_deadman+0x30 > #4 0xffffffff81034cc0 at vdev_deadman+0x30 > #5 0xffffffff810298e5 at spa_deadman+0x85 > #6 0xffffffff805b8ca5 at softclock_call_cc+0x165 > #7 0xffffffff805b90b4 at softclock+0x94 > #8 0xffffffff805716cb at intr_event_execute_handlers+0xab > #9 0xffffffff80571b16 at ithread_loop+0x96 > #10 0xffffffff8056f19a at fork_exit+0x9a > #11 0xffffffff807a817e at fork_trampoline+0xe > Uptime: 59s On Sun, Sep 13, 2015 at 6:03 AM, Steven Hartland wrote: > > Do you remember if this was this causing a deadlock or something similar that's easy to provoke? > > Regards > Steve > > > On 11/09/2015 18:00, Alexander Motin wrote: >> >> Hi. >> >> The code in question was added by me at r253992. Commit message tells it >> was made to decouple locks. I don't remember much more details, but may >> be it can be redone somehow else. >> >> On 11.09.2015 19:07, Matthew Ahrens wrote: >>> >>> I discovered that when destroying a ZFS snapshot, we can end up using >>> several seconds of CPU via this stack trace: >>> >>> kernel`spinlock_exit+0x2d >>> kernel`taskqueue_enqueue+0x12c >>> zfs.ko`zio_issue_async+0x7c >>> zfs.ko`zio_execute+0x162 >>> zfs.ko`dsl_scan_free_block_cb+0x15f >>> zfs.ko`bpobj_iterate_impl+0x25d >>> zfs.ko`bpobj_iterate_impl+0x46e >>> zfs.ko`dsl_scan_sync+0x152 >>> zfs.ko`spa_sync+0x5c1 >>> zfs.ko`txg_sync_thread+0x3a6 >>> kernel`fork_exit+0x9a >>> kernel`0xffffffff80d0acbe >>> 6558 ms >>> >>> This is not good for performance since, in addition to the CPU cost, it >>> doesn't allow the sync thread to do anything else, and this is >>> observable as periods where we don't do any write i/o to disk for >>> several seconds. >>> >>> The problem is that when zfs_trim_enabled is set (which it is by >>> default), zio_free_sync() always sets ZIO_STAGE_ISSUE_ASYNC, causing th= e >>> free to be dispatched to a taskq. Since each task completes very >>> quickly, there is a large locking and context switching overhead -- we >>> would be better off just processing the free in the caller's context. >>> >>> I'm not sure exactly why we need to go async when trim is enabled, but >>> it seems like at least we should not bother going async if trim is not >>> actually being used (e.g. with an all-spinning-disk pool). It would >>> also be worth investigating not going async even when trim is useful >>> (e.g. on SSD-based pools). >>> >>> Here is the relevant code: >>> >>> zio_free_sync(): >>> if (zfs_trim_enabled) >>> stage |=3D ZIO_STAGE_ISSUE_ASYNC | ZIO_STAGE_VDEV_IO_START | >>> ZIO_STAGE_VDEV_IO_ASSESS; >>> /* >>> * GANG and DEDUP blocks can induce a read (for the gang block >>> header, >>> * or the DDT), so issue them asynchronously so that this thread is >>> * not tied up. >>> */ >>> else if (BP_IS_GANG(bp) || BP_GET_DEDUP(bp)) >>> stage |=3D ZIO_STAGE_ISSUE_ASYNC; >>> >>> --matt >> >> > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" -- Sean Chittenden From owner-freebsd-fs@freebsd.org Tue Sep 15 00:03:31 2015 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 A77DAA04848 for ; Tue, 15 Sep 2015 00:03:31 +0000 (UTC) (envelope-from gdt@ir.bbn.com) Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [IPv6:2001:4978:1fb:6400::d2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "fnord.ir.bbn.com", Issuer "ir.bbn.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 670A91C0C for ; Tue, 15 Sep 2015 00:03:31 +0000 (UTC) (envelope-from gdt@ir.bbn.com) Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 8ADD2A9A4; Mon, 14 Sep 2015 20:03:28 -0400 (EDT) From: Greg Troxel To: Jordan Hubbard Cc: Rick Macklem , freebsd-fs@freebsd.org, Rakshith Venkatesh Subject: Re: CEPH + FreeBSD References: <100306673.40344407.1441279047901.JavaMail.zimbra@uoguelph.ca> <1564D4FA-9BE1-4E37-8E91-F14A009D6B62@icloud.com> OpenPGP: id=32611E25 X-Hashcash: 1:20:150914:jordanhubbard@icloud.com::8ZEbUJ+4ZIZMLCyy:00000000000000000000000000000000000004PlP X-Hashcash: 1:20:150914:vrock28@gmail.com::yBlvdFhehOkh+BeS:000000000000000000000000000000000000000000004WQE X-Hashcash: 1:20:150914:rmacklem@uoguelph.ca::w2uU806t1U2ycNHb:000000000000000000000000000000000000000006o+m X-Hashcash: 1:20:150914:freebsd-fs@freebsd.org::yk8vjmBKTa0Hiejy:000000000000000000000000000000000000000Tlre Date: Mon, 14 Sep 2015 20:03:28 -0400 In-Reply-To: <1564D4FA-9BE1-4E37-8E91-F14A009D6B62@icloud.com> (Jordan Hubbard's message of "Sat, 05 Sep 2015 22:19:50 -0700") Message-ID: User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 00:03:31 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jordan Hubbard writes: > One is glusterfs, for which I=E2=80=99m not even really clear on the stat= us of > the ports for. I don=E2=80=99t see any glusterfs port in the master bran= ch of > https://github.com/freebsd/freebsd-ports (or > https://github.com/freebsd/freebsd-ports/tree/branches/2015Q3 for that > matter). > > [snip] > > I=E2=80=99m not really sure about the provenance since we were simply > evaluating glusterfs for awhile and may have pulled in interim > versions from those sources, but obviously it would be best to have an > official maintainer and someone in the FreeBSD project actually > curating a glusterfs port so that all users of FreeBSD can use it. It > would also be fairly key to your own efforts, assuming you decide to > pursue glusterfs as a foundation technology for pNFS. Emmanual Dreyfus has been working on glusterfs for NetBSD, and it seems to work quite well. So most of the BSD-shared porrtability issues are worked out. gluster needs the low level FUSE API. On NetBSD, we have puffs in the kernel which is FUSE-like, and librefuse to impelment FUSE on puffs (all BSD licensed). Then there is a low-level API daemon perfuse. gluster and perfuse are in pkgsrc. So if FreeBSD has the low-level FUSE API, it will probably mostly work. However, gluster was a tough user of FUSE, and shook out a lot of obscure edge cases. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlX3YFAACgkQ+vesoDJhHiX3vACeKdm1OTv0DyM+XkYiOu2ULSzG ox0AoIANnRCdAXZJ06V76Ohg2OFyD9DB =+RIe -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-fs@freebsd.org Tue Sep 15 07:43:34 2015 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 6167CA033DD for ; Tue, 15 Sep 2015 07:43: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 4D58F10C2 for ; Tue, 15 Sep 2015 07:43: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 t8F7hYKc042690 for ; Tue, 15 Sep 2015 07:43:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 183328] freebsd-update upgrade from 9.1 to 9.2 for zfs on root results in unbootable system Date: Tue, 15 Sep 2015 07:43:34 +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: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 07:43:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183328 Garrett Cooper,425-314-3911 changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org CC| |ngie@FreeBSD.org --- Comment #1 from Garrett Cooper,425-314-3911 --- (In reply to dms from comment #0) Unfortunately the forum page is a 404 now :(. I'm guessing you ran into a slew of errors like "boot: ZFS: i/o error - all block copies unavailable". I recently replaced a spinning rust disk with an SSD (with 4kB sectors), installed 9.3, upgraded to the latest point release, and unfortunately ran into this unbootable scenario, similar to what you've described below. I had to wipe out my root zpool and repartition the SSD. Fortunately I didn't have any critical data on it, but it was unfortunate that I had to hop through that hoop in order to get my system back in working shape.. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Tue Sep 15 07:44:11 2015 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 41045A03463 for ; Tue, 15 Sep 2015 07:44:11 +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 2D41411BB for ; Tue, 15 Sep 2015 07:44:11 +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 t8F7iBEb043388 for ; Tue, 15 Sep 2015 07:44:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 183328] freebsd-update upgrade from 9.1 to 9.2 for zfs on root results in unbootable system Date: Tue, 15 Sep 2015 07:44:11 +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: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_severity Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 07:44:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183328 Garrett Cooper,425-314-3911 changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Only Me |Affects Some People -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Wed Sep 16 00:24:51 2015 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 129259C2137 for ; Wed, 16 Sep 2015 00:24:51 +0000 (UTC) (envelope-from jordanhubbard@icloud.com) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5A7D1350 for ; Wed, 16 Sep 2015 00:24:50 +0000 (UTC) (envelope-from jordanhubbard@icloud.com) X-ASG-Debug-ID: 1442363089-08ca04166bf6c50001-3nHGF7 Received: from mail.iXsystems.com ([10.2.55.1]) by barracuda.ixsystems.com with ESMTP id w9fMoYqxcrGp9Kuf (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 Sep 2015 17:24:49 -0700 (PDT) X-Barracuda-Envelope-From: jordanhubbard@icloud.com X-Barracuda-RBL-Trusted-Forwarder: 10.2.55.1 X-ASG-Whitelist: Client Received: from [10.5.0.84] (unknown [10.5.0.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 3341799966; Tue, 15 Sep 2015 17:24:49 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Subject: Re: CEPH + FreeBSD From: Jordan Hubbard X-ASG-Orig-Subj: Re: CEPH + FreeBSD In-Reply-To: Date: Tue, 15 Sep 2015 17:27:41 -0700 Cc: freebsd-fs@freebsd.org, Rakshith Venkatesh , Xin LI , Josh Paetzel , Sean Fagan Message-Id: <298B99CD-45A2-40AB-9E16-5AD983AFE1B2@icloud.com> References: <100306673.40344407.1441279047901.JavaMail.zimbra@uoguelph.ca> <1564D4FA-9BE1-4E37-8E91-F14A009D6B62@icloud.com> To: Greg Troxel X-Mailer: Apple Mail (2.3094) X-Barracuda-Connect: UNKNOWN[10.2.55.1] X-Barracuda-Start-Time: 1442363089 X-Barracuda-Encrypted: DHE-RSA-CAMELLIA256-SHA X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 00:24:51 -0000 Hi Greg, Thanks for the pointer to this work. It sounds like the FUSE code in = FreeBSD and NetBSD have diverged significantly. Does anyone know what = originally drove NetBSD in the direction of this =E2=80=9Cpuffs=E2=80=9D = reimplementation? I=E2=80=99m not saying the FUSE code is awesome and = in need of defending, I=E2=80=99m just trying to understand the = rationale behind =E2=80=9CreFUSING=E2=80=9D it. :) If it=E2=80=99s also demonstrably and clearly better, we should probably = make this a target for merging between the *BSDs since we have a growing = number of foreign-filesystem import and now gluster targets that use it. Cheers, - Jordan > On Sep 14, 2015, at 5:03 PM, Greg Troxel wrote: >=20 > Emmanual Dreyfus has been working on glusterfs for NetBSD, and it = seems > to work quite well. So most of the BSD-shared porrtability issues are > worked out. gluster needs the low level FUSE API. On NetBSD, we have > puffs in the kernel which is FUSE-like, and librefuse to impelment = FUSE > on puffs (all BSD licensed). Then there is a low-level API daemon > perfuse. gluster and perfuse are in pkgsrc. >=20 > So if FreeBSD has the low-level FUSE API, it will probably mostly = work. > However, gluster was a tough user of FUSE, and shook out a lot of > obscure edge cases. From owner-freebsd-fs@freebsd.org Wed Sep 16 01:03:04 2015 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 837FD9CDA3C for ; Wed, 16 Sep 2015 01:03:04 +0000 (UTC) (envelope-from gdt@ir.bbn.com) Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [192.1.100.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "fnord.ir.bbn.com", Issuer "ir.bbn.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4313B19F9 for ; Wed, 16 Sep 2015 01:03:04 +0000 (UTC) (envelope-from gdt@ir.bbn.com) Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 78CECB31F; Tue, 15 Sep 2015 20:43:04 -0400 (EDT) From: Greg Troxel To: Jordan Hubbard Cc: freebsd-fs@freebsd.org, Rakshith Venkatesh , Xin LI , Josh Paetzel , Sean Fagan Subject: Re: CEPH + FreeBSD References: <100306673.40344407.1441279047901.JavaMail.zimbra@uoguelph.ca> <1564D4FA-9BE1-4E37-8E91-F14A009D6B62@icloud.com> <298B99CD-45A2-40AB-9E16-5AD983AFE1B2@icloud.com> OpenPGP: id=32611E25 X-Hashcash: 1:20:150916:freebsd-fs@freebsd.org::Gk/bcQ3QNxAGVdEy:0000000000000000000000000000000000000000cdx X-Hashcash: 1:20:150916:d@delphij.net::VuvNQ5iIO4NDNoyn:00002mqq X-Hashcash: 1:20:150916:sef@ixsystems.com::hgs9KHw30FDLu3zp:000000000000000000000000000000000000000000000OCS X-Hashcash: 1:20:150916:jordanhubbard@icloud.com::URvNqHOAqY0GBKGG:00000000000000000000000000000000000000w5c X-Hashcash: 1:20:150916:vrock28@gmail.com::cvUITH9RQIAMrxIX:000000000000000000000000000000000000000000000d0p X-Hashcash: 1:20:150916:jpaetzel@ixsystems.com::hUlz+RPbiZzbNz23:000000000000000000000000000000000000000AOBY Date: Tue, 15 Sep 2015 20:43:00 -0400 In-Reply-To: <298B99CD-45A2-40AB-9E16-5AD983AFE1B2@icloud.com> (Jordan Hubbard's message of "Tue, 15 Sep 2015 17:27:41 -0700") Message-ID: User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 01:03:04 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jordan Hubbard writes: > Thanks for the pointer to this work. It sounds like the FUSE code in > FreeBSD and NetBSD have diverged significantly. I would describe it that FreeBSD has code ported from FUSE (but I'm not sure) and NetBSD has a puffs-based reimplementation, and there isn't much if any common ancestry. > Does anyone know what originally drove NetBSD in the direction of this > =E2=80=9Cpuffs=E2=80=9D reimplementation? I=E2=80=99m not saying the FUS= E code is awesome and > in need of defending, I=E2=80=99m just trying to understand the rationale > behind =E2=80=9CreFUSING=E2=80=9D it. :) I think it was a combination of discomfort with the code and wanting to have a BSD-licensed implementation. There were papers at AsiaBSDCON 2007, I believe. It may also be related to the rump concept, where kernel code can run in userspace and be glued back into the kernel. That requires proxying vnodeops to the userspace program, which (wave hands wildly) is a little more involved than what FUSE requires. On NetBSD you can e.g mount a msdos fs with the rump option so that the msdos kernel code is actually in a user process, which accesses the disk, and vnodeops in the normal kernel get passed to the process. So it's mostly like kernel code with an extra rpc layer and you can run gdb on the user process and if it crashes you just lose the fs and not the whole kernel. > If it=E2=80=99s also demonstrably and clearly better, we should probably = make > this a target for merging between the *BSDs since we have a growing > number of foreign-filesystem import and now gluster targets that use > it. I think it would be great if you snarfed puffs (and rump). We need to take ZFS and jails from FreeBSD :-) References from NetBSD puffs(3): Antti Kantee, "puffs - Pass-to-Userspace Framework File System", Proceedings of AsiaBSDCon 2007, pp. 29-42, March 2007. Antti Kantee, Using puffs for Implementing Client-Server Distributed F= ile Systems, Helsinki University of Technology, Tech Report TKK-TKO-B157, September 2007. Antti Kantee and Alistair Crooks, "ReFUSE: Userspace FUSE Reimplementation Using puffs", EuroBSDCon 2007, September 2007. Antti Kantee, "Send and Receive of File System Protocols: Userspace Approach With puffs", Proceedings of AsiaBSDCon 2008, pp. 55-70, March 2008. A more recent summary that talks about gluster http://hcpnet.free.fr/pubz/#fuse --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlX4uxQACgkQ+vesoDJhHiWbmACeJWYd/sBjou3d6bLFY81qFh4f RUkAn0F/MdrXMXz++sOYnfyyeaHba7LZ =lcfz -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-fs@freebsd.org Wed Sep 16 16:30:36 2015 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 4C5969C28D9 for ; Wed, 16 Sep 2015 16:30:36 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 1CC7F1CB7 for ; Wed, 16 Sep 2015 16:30:35 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: by ioiz6 with SMTP id z6so234894219ioi.2 for ; Wed, 16 Sep 2015 09:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=5IFYWb3IHMDZsk6zJzWLtjcK+UvR6XsnWTRBsfJPjKU=; b=pF11sW/qBq8enoA9Su+Vo9z5tqkp3pOy/jYP7WQJu3p1ITNl7sNZZQd/bzEkpnJGLA C+Ek50ZmobHYkDdGbJezBbFMy6Kys0JqSREubqLuXNW2dy2ixPBUpaP/JfVKcb+1X4B4 /wzrAmfxzMyzDjyXpvYnwITucr1YdjvKnKxt0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=5IFYWb3IHMDZsk6zJzWLtjcK+UvR6XsnWTRBsfJPjKU=; b=QsFst08ebUefOVrZRUPZASXf+h0NgU2KUjkFtIjEsjytt7wRpLXiPRwOgk6uJHWT4K 4EXJqCBGbNbF1Wov1+QEhrnILxf9bzDFoWnykoa5aPRN4pOoovflFKsnTW5hwy5EMJYE 95aJO8JJT8LXSFY4Z+SMymAwzU/F71HeHKqFIi23Clc2SWJiBY9KrsI8dLqfSyImacB8 SIQCBVdJiaXl+Jl/vKV2kxle46YBxqjBYTj5/MYdYVc8gc+H41VUN4/Yytclbqq1Lpfk 5V9Ea9EbXFVbL8l6JLBNIjmPzSxWgSI3xYTvmeL6IcEGIVALCUTdxNto4HlRYIKgd4nV x1tw== X-Gm-Message-State: ALoCoQnXC0VNi8WrElkhqN3mqem9Row/Q/1OaqqV57CrVQ0NyWhfaaU15h1eoh1Anc7L2pafM7ij X-Received: by 10.107.137.75 with SMTP id l72mr1556152iod.121.1442421035202; Wed, 16 Sep 2015 09:30:35 -0700 (PDT) Received: from unassigned.v6.your.org ([2001:4978:1:45:7029:bae0:76fe:ae62]) by smtp.gmail.com with ESMTPSA id a4sm2220968igh.16.2015.09.16.09.30.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Sep 2015 09:30:34 -0700 (PDT) From: Kevin Day Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Neutered devices in jails (per FS flag?) Message-Id: Date: Wed, 16 Sep 2015 11:30:33 -0500 To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 16:30:36 -0000 We=E2=80=99re currently using jails to allow servers to copy backups of = themselves to a central backup server. The problem we=E2=80=99re having = is with mknod/devices. Currently jails don=E2=80=99t allow device files = to be created, which makes sense - you don=E2=80=99t want them to be = able to bypass the jail by opening /dev/kmem or something. We want jails = to be able to create device files, just not be able to open/use them. Has anyone given any thought to changing this behavior? Allowing jails = to create/manipulate device files, but not actually opening them? I.e. = instead of returning EPERM on creating the device, instead return EPERM = on opening it? This would likely need to be a filesystem flag, because = jails still require some devices to work (a separate devfs mount or = something). We could make the jail=E2=80=99s /dev read only or use devfs = so those devices still work, but have the parent jail directory with a = =E2=80=9Cnoopendev=E2=80=9D flag or something similar. Has anyone gone down this path before? =E2=80=94 Kevin From owner-freebsd-fs@freebsd.org Wed Sep 16 16:57:01 2015 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 B85139CD6D9 for ; Wed, 16 Sep 2015 16:57:01 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (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 7E0831D31 for ; Wed, 16 Sep 2015 16:57:01 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.local (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id BA32F6621 for ; Wed, 16 Sep 2015 18:56:58 +0200 (CEST) Subject: Re: Neutered devices in jails (per FS flag?) To: freebsd-fs@freebsd.org References: From: Jan Bramkamp Message-ID: <55F99F5A.302@rlwinm.de> Date: Wed, 16 Sep 2015 18:56:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 16:57:01 -0000 On 16/09/15 18:30, Kevin Day wrote: > We’re currently using jails to allow servers to copy backups of themselves to a central backup server. The problem we’re having is with mknod/devices. Currently jails don’t allow device files to be created, which makes sense - you don’t want them to be able to bypass the jail by opening /dev/kmem or something. We want jails to be able to create device files, just not be able to open/use them. > > Has anyone given any thought to changing this behavior? Allowing jails to create/manipulate device files, but not actually opening them? I.e. instead of returning EPERM on creating the device, instead return EPERM on opening it? This would likely need to be a filesystem flag, because jails still require some devices to work (a separate devfs mount or something). We could make the jail’s /dev read only or use devfs so those devices still work, but have the parent jail directory with a “noopendev” flag or something similar. > > Has anyone gone down this path before? There is no reason to backup device files on FreeBSD because FreeBSD uses a dynamic devfs. Backup the devfs rules and devfs.conf instead of the device files. From owner-freebsd-fs@freebsd.org Wed Sep 16 16:58:42 2015 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 3AD699CD796 for ; Wed, 16 Sep 2015 16:58:42 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 000731DD5 for ; Wed, 16 Sep 2015 16:58:41 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: by iofb144 with SMTP id b144so237210869iof.1 for ; Wed, 16 Sep 2015 09:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vGpWoB/h6gCRZ4DExnd/aebPMpjNVUTgguAowILf4PQ=; b=XbXagU89YMx+cNTzdEGQuhzbZiA1LA4TFrlKiX9ydqT1+7oT1PH9mBRnoCjYrFh7QV zBswpL2L7xUu3pgWT4qA6ZkJ6PwoCjgC8PGS+FGmz0XMEkpETC2815pHlnBZa2zYgM89 4et/nnlLlpJSVovv9YcPgF5NnHrcsf3H7SfNU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=vGpWoB/h6gCRZ4DExnd/aebPMpjNVUTgguAowILf4PQ=; b=avw7vqeTrrB/koYoCt+SME3jm/kEhYg+aIL1ITgqVFEzgJlDW6WSmSMPXBNj7QYo/l CEimOuXtfgEmMoJ6SbkqKzqsAkpbvFe+8B/Z/rRuHKeWkLy9ICmRZLxYc0DPwAZdtwM0 IB3BzK0f1+j8SUcf/bEpbCFm3R5euWbzChSxBH9VaRyOxs1yvpD5/ZXDCu+uJ6DXgMLt U1+oKu2qLGTiru0X28Ld4EFPzXbTUCrYRwQQn0gxjzYDJsorngKeT8ks4xaA5uzYbUFn LMv6cn/lNSVSM2lXODKFamAfHwwR9tSV8eulbTExu0xKimo+8wI55lKia1INSOT05s/v Z+2w== X-Gm-Message-State: ALoCoQkLAFqtFUWOaBcsiRVxP3j1s+WOG0pBXFawY5V3kGiq19oudpUHPvM6xvSDASc0sBvOaNNr X-Received: by 10.107.34.18 with SMTP id i18mr46055200ioi.149.1442422721359; Wed, 16 Sep 2015 09:58:41 -0700 (PDT) Received: from unassigned.v6.your.org ([2001:4978:1:45:7029:bae0:76fe:ae62]) by smtp.gmail.com with ESMTPSA id 20sm10744622ioj.25.2015.09.16.09.58.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Sep 2015 09:58:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Subject: Re: Neutered devices in jails (per FS flag?) From: Kevin Day In-Reply-To: <55F99F5A.302@rlwinm.de> Date: Wed, 16 Sep 2015 11:58:38 -0500 Cc: freebsd-fs@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7D445BFC-AB18-4EAD-8065-F0A934B1A479@dragondata.com> References: <55F99F5A.302@rlwinm.de> To: Jan Bramkamp X-Mailer: Apple Mail (2.3094) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 16:58:42 -0000 > On 16/09/15 18:30, Kevin Day wrote: >> We=E2=80=99re currently using jails to allow servers to copy backups = of themselves to a central backup server. The problem we=E2=80=99re = having is with mknod/devices. Currently jails don=E2=80=99t allow device = files to be created, which makes sense - you don=E2=80=99t want them to = be able to bypass the jail by opening /dev/kmem or something. We want = jails to be able to create device files, just not be able to open/use = them. >>=20 >> Has anyone given any thought to changing this behavior? Allowing = jails to create/manipulate device files, but not actually opening them? = I.e. instead of returning EPERM on creating the device, instead return = EPERM on opening it? This would likely need to be a filesystem flag, = because jails still require some devices to work (a separate devfs mount = or something). We could make the jail=E2=80=99s /dev read only or use = devfs so those devices still work, but have the parent jail directory = with a =E2=80=9Cnoopendev=E2=80=9D flag or something similar. >>=20 >> Has anyone gone down this path before? >=20 > There is no reason to backup device files on FreeBSD because FreeBSD = uses a dynamic devfs. Backup the devfs rules and devfs.conf instead of = the device files. We=E2=80=99re backing up non-FreeBSD systems, as well as some software = that creates its own devices inside a mini-chroot it needs to run. From owner-freebsd-fs@freebsd.org Thu Sep 17 00:39:40 2015 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 338709CE16E for ; Thu, 17 Sep 2015 00:39:40 +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 1FFD21A5B for ; Thu, 17 Sep 2015 00:39:40 +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 t8H0ddUV057271 for ; Thu, 17 Sep 2015 00:39:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 203134] [nfs] [nlm] [lor] newnfs/allproc lock order reversal on NFS mount recovery Date: Thu, 17 Sep 2015 00:39:40 +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-BETA2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 00:39:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203134 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Thu Sep 17 00:39:51 2015 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 06C969CE1A9 for ; Thu, 17 Sep 2015 00:39:51 +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 E87BE1AFD for ; Thu, 17 Sep 2015 00:39:50 +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 t8H0doEB057647 for ; Thu, 17 Sep 2015 00:39:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 203133] [nfs] [lor] newnfs/proctree lock order reversal Date: Thu, 17 Sep 2015 00:39:50 +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-BETA2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 00:39:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203133 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Thu Sep 17 01:09:46 2015 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 CB1099CD008 for ; Thu, 17 Sep 2015 01:09:46 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 A5618164A for ; Thu, 17 Sep 2015 01:09:46 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: by igcpb10 with SMTP id pb10so2067173igc.1 for ; Wed, 16 Sep 2015 18:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=gXf4sfY5R1Oa7AR1U6/4zVLvQBRevhYfCXJI5Gd7FMI=; b=K7cs4Kyx8XZ3qngi6qf/5X24rQS5iOMRNj0VS1yJcsR1Jvd+715Pw6Dy8qRW+XBYbu ubdPYVFhOuYZRi9aIFQxj5Grs7tyxk0pnW2Ogk7heIci7KD/u25qLoaHt6sAV6u6ZbSo qf0oTsJfhsLVJ9WTksvsx2RtcFfTbMWjNU8Qc= 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 :content-type; bh=gXf4sfY5R1Oa7AR1U6/4zVLvQBRevhYfCXJI5Gd7FMI=; b=N2rII63Yv8t1Q8lsHTTVctqf+6LfXdgYijMcNmW8/sVfA9/SHbfG7+me+Ej/biu16L dg3CppheG+ZgZewVRghSC3f1JffxSKg9Fq/bvRBsGZA2/gr7rhfoZbs8LxonIeuUe9pq zzhSS25br7Z8apKPAk7M6+CHMZeRTG/zfgiKHqWVpSqKVkvmQpC7jnkj3C7cf7awReBl /+O+sAATaIDlOVBn7Tp15FzzZJE6Fty1ZgQMwyJDPnBO+DzO5fw6A2KLK0sbPnoY2wdq 4q6uY8I5kpN3AQqc4dj4M2rY01ukFeh7Ogh3NasKVMr1O/MGB9fkSuAU5XjA1nV5/KHd afYw== X-Gm-Message-State: ALoCoQmH9JMppBuPiZ+PuUf1wfZTyPwD8jEAGG3muubbYkFfpc2bEHlnkTA1ZBOGcjTL5TcepBZO MIME-Version: 1.0 X-Received: by 10.50.33.14 with SMTP id n14mr1528576igi.95.1442452185629; Wed, 16 Sep 2015 18:09:45 -0700 (PDT) Received: by 10.36.86.208 with HTTP; Wed, 16 Sep 2015 18:09:45 -0700 (PDT) Date: Wed, 16 Sep 2015 18:09:45 -0700 Message-ID: Subject: changing space map blksz, commit from illumos From: Matthew Ahrens To: freebsd-fs Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 01:09:47 -0000 I would like to change the space map block size on FreeBSD, to improve performance on a system with very large vdevs. This was made possible in illumos (exactly!) a year ago by the commit below. Does anyone know if there's a technical reason that this was not ported to FreeBSD? If not, it would be great if someone wants to pick it up, otherwise I'll try to do so when I have time. commit b1be2892dd07cf9a97d47ad06334cdc879196aaf Author: Matthew Ahrens Date: Tue Sep 16 11:53:58 2014 -0800 5164 space_map_max_blksz causes panic, does not work 5165 zdb fails assertion when run on pool with recently-enabled spacemap_histogram feature Reviewed by: Christopher Siden Reviewed by: George Wilson Reviewed by: Saso Kiselkov Approved by: Dan McDonald --matt From owner-freebsd-fs@freebsd.org Thu Sep 17 01:40:50 2015 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 3DF049CE0DA for ; Thu, 17 Sep 2015 01:40:50 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 054761365 for ; Thu, 17 Sep 2015 01:40:50 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: by igbkq10 with SMTP id kq10so46322194igb.0 for ; Wed, 16 Sep 2015 18:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=B+eZoA9m0oR7QFpy17mSXikFXz44LuaxlQUdlIzNlec=; b=DzCWEcjLrML7maLQBApQlVV0Njt+FWZvmhMV1h/vt+Yv5tAUs7SSL1Cdfx+xzycsp9 wKbiXKyQGIpncvBtyQGQz0KwgMHMM5dwQKwqnzjJ7CYFimsRw51xCtbh/vaa7f0SCxWG K3f6VOPjM4HrgnYvsj4O4nuL9PKOiUziJsaOQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=B+eZoA9m0oR7QFpy17mSXikFXz44LuaxlQUdlIzNlec=; b=XhKHHhr77sB+/xF5c/R7/FHgOuLgEGJ8FzNgSOgoOEZeO7uNdhbkMJnRe+5k1r0EjH ch2Qk/Ca8lyQzNuGupOQI6/j78zV7H7CAOL8GvYu2ztnMLNXNDQgDzJERn6Ys0fMDAAS KXKWhzp6nj3EmP4bU6vVuCYGbOoteNqkUWScrlDigz5+3VyqbKe5mTCb05DPvEWUk19B T3G6469pJYnIimcCs5VH71xFU1uflX+IsfqmVyJQtgCZlpVDSCUbwJ86fKypHcxkRHGV IDSBtB9TWTzbifPwadnl4JH1Jmzz1jojoGr7h6p7b0jMjexge7VFouv8wVlwUM7AtQpO 2fYg== X-Gm-Message-State: ALoCoQniXK8pXVhA0IeyCMThYZT8MIeXzPLhlKvc9uBUfNGvysjULt84bWRNKKdt+GXjbe/3k80A MIME-Version: 1.0 X-Received: by 10.50.50.240 with SMTP id f16mr20972216igo.95.1442454049375; Wed, 16 Sep 2015 18:40:49 -0700 (PDT) Received: by 10.36.86.208 with HTTP; Wed, 16 Sep 2015 18:40:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Sep 2015 18:40:49 -0700 Message-ID: Subject: Re: changing space map blksz, commit from illumos From: Matthew Ahrens To: freebsd-fs Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 01:40:50 -0000 Xin pointed out that this change is in head. The problem is that I was looking at release/10.1.0. Looks like it's already in releng/10.2 so that's great, sorry for the noise! --matt On Wed, Sep 16, 2015 at 6:09 PM, Matthew Ahrens wrote: > I would like to change the space map block size on FreeBSD, to improve > performance on a system with very large vdevs. This was made possible in > illumos (exactly!) a year ago by the commit below. Does anyone know if > there's a technical reason that this was not ported to FreeBSD? If not, it > would be great if someone wants to pick it up, otherwise I'll try to do so > when I have time. > > commit b1be2892dd07cf9a97d47ad06334cdc879196aaf > Author: Matthew Ahrens > Date: Tue Sep 16 11:53:58 2014 -0800 > > 5164 space_map_max_blksz causes panic, does not work > 5165 zdb fails assertion when run on pool with recently-enabled > spacemap_histogram feature > Reviewed by: Christopher Siden > Reviewed by: George Wilson > Reviewed by: Saso Kiselkov > Approved by: Dan McDonald > > --matt > From owner-freebsd-fs@freebsd.org Fri Sep 18 01:06:04 2015 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 EA3359CE89A for ; Fri, 18 Sep 2015 01:06:04 +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 D67D31FB5 for ; Fri, 18 Sep 2015 01:06:04 +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 t8I164C4085362 for ; Fri, 18 Sep 2015 01:06:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 203185] mountd is exposing parent directories [on zfs mount?] that it should not be Date: Fri, 18 Sep 2015 01:06:04 +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 Only Me X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 01:06:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203185 Garrett Cooper,425-314-3911 changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rmacklem@FreeBSD.org Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --- Comment #1 from Garrett Cooper,425-314-3911 --- Likely a FreeBSD FS bug. I have 9.3/10.2/a more recent version of CURRENT installed on a few different machines at home (some with and some without ZFS). I'll try and repro this issue there. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Fri Sep 18 05:54:44 2015 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 DF2429CF349 for ; Fri, 18 Sep 2015 05:54:44 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (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 A0218191B for ; Fri, 18 Sep 2015 05:54:44 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-224-161.lns20.per1.internode.on.net [121.45.224.161]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id t8I5sZW2081022 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 Sep 2015 22:54:38 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Neutered devices in jails (per FS flag?) To: Kevin Day , Jan Bramkamp References: <55F99F5A.302@rlwinm.de> <7D445BFC-AB18-4EAD-8065-F0A934B1A479@dragondata.com> Cc: freebsd-fs@freebsd.org From: Julian Elischer Message-ID: <55FBA715.707@freebsd.org> Date: Fri, 18 Sep 2015 13:54:29 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <7D445BFC-AB18-4EAD-8065-F0A934B1A479@dragondata.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 05:54:45 -0000 On 9/17/15 12:58 AM, Kevin Day wrote: >> On 16/09/15 18:30, Kevin Day wrote: >>> We’re currently using jails to allow servers to copy backups of themselves to a central backup server. The problem we’re having is with mknod/devices. Currently jails don’t allow device files to be created, which makes sense - you don’t want them to be able to bypass the jail by opening /dev/kmem or something. We want jails to be able to create device files, just not be able to open/use them. >>> >>> Has anyone given any thought to changing this behavior? Allowing jails to create/manipulate device files, but not actually opening them? I.e. instead of returning EPERM on creating the device, instead return EPERM on opening it? This would likely need to be a filesystem flag, because jails still require some devices to work (a separate devfs mount or something). We could make the jail’s /dev read only or use devfs so those devices still work, but have the parent jail directory with a “noopendev” flag or something similar. >>> >>> Has anyone gone down this path before? >> There is no reason to backup device files on FreeBSD because FreeBSD uses a dynamic devfs. Backup the devfs rules and devfs.conf instead of the device files. > We’re backing up non-FreeBSD systems, as well as some software that creates its own devices inside a mini-chroot it needs to run. you can't create device files under FreeBSD...... well, you can make the nodes I guess but they don't connect to any device.. they only exist to allow them to be exported through NFS as far as I know. > > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > From owner-freebsd-fs@freebsd.org Fri Sep 18 06:35:49 2015 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 034879CD539 for ; Fri, 18 Sep 2015 06:35:49 +0000 (UTC) (envelope-from tjg@ucsc.edu) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 9311D1C1E for ; Fri, 18 Sep 2015 06:35:48 +0000 (UTC) (envelope-from tjg@ucsc.edu) Received: by wicfx3 with SMTP id fx3so50767178wic.1 for ; Thu, 17 Sep 2015 23:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:date:message-id:subject:from:to:content-type; bh=6llpjw0Qcsrm4jhIVPikYwKlxm7Ltl0uINmJJkq/4+w=; b=BDrytVZ9iGbSc1LVTyF5q6ejOqSO0be6z4D2h4mAMYBFQYdpmayoe15/f2YnRIUlJY NkA0SL6JM1/8ZfNQ2WP9xr37pxYalRmokVbAjI1YWuJukkuSGsxPYsZlYLR25YHHRMJk VFBpMutH5tyO53ivDsxr/03eSUQBso8+rWKjg= 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 :content-type; bh=6llpjw0Qcsrm4jhIVPikYwKlxm7Ltl0uINmJJkq/4+w=; b=M1UVPnR577SCyegj6s1n5F62bpRULz42upl50Qy19Wj64wY7zFvaDoDOzI/6g8qQAf 1++7WEEcNea6Lwvxc1bQvaxm46zynjqkApDTrSPhgCFKXp/Kw2fAw87MeSRKEqFFaRHC qvAuc1UhXAyZIyobM6u+RQUR1oSmWj1kyi0eHwmzOpkVyFm2rQ8ufnvk+zVr+DiedMIa 7/n4/LnJHsgr99EAyPC8JHWK9ZTaWCn7qvDselvorM6AOwyv1A5mHyTB6Wpl83QXRPQg MSmKq0XpDOUSyXUDnv2akriNasSMsslyteWNKtMqtguXrrG/QxnkavKs1wmXaCg9CoDJ 1RFw== X-Gm-Message-State: ALoCoQm+cwX513ZVcxmc/cFk3XPvOuB4L08q1o6LivpXpZI1IwvkzR8MH9SFdSohQK4pDcQU90+O MIME-Version: 1.0 X-Received: by 10.180.8.132 with SMTP id r4mr37670923wia.70.1442558146951; Thu, 17 Sep 2015 23:35:46 -0700 (PDT) Received: by 10.194.92.209 with HTTP; Thu, 17 Sep 2015 23:35:46 -0700 (PDT) Date: Thu, 17 Sep 2015 23:35:46 -0700 Message-ID: Subject: FreeBSD 10.1 + Samsung 850 EVO + ZFS + TRIM From: Tim Gustafson To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 06:35:49 -0000 Hi, I've Google this around a bit, but I seem to be getting some conflicting information so I'm hoping I can get this cleared up here. I have a shiny new Dell PowerEdge R630 with four 1TB Samsung EVO SSDs installed and configured as a RAID 0+1 zpool: pool: tank state: ONLINE scan: scrub repaired 14.5K in 0h13m with 0 errors on Thu Sep 17 20:47:17 2015 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 mfisyspd0p3 ONLINE 0 0 0 mfisyspd1p3 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 mfisyspd3p3 ONLINE 0 0 0 mfisyspd2p3 ONLINE 0 0 0 errors: No known data errors I was investigating whether or not TRIM support was working, so I did: root@host: sysctl -a | grep trim vfs.zfs.vdev.trim_on_init: 1 vfs.zfs.vdev.trim_min_active: 1 vfs.zfs.vdev.trim_max_active: 64 vfs.zfs.vdev.trim_max_bytes: 2147483648 vfs.zfs.vdev.trim_max_pending: 64 vfs.zfs.trim.enabled: 1 vfs.zfs.trim.txg_delay: 32 vfs.zfs.trim.timeout: 30 vfs.zfs.trim.max_interval: 1 kstat.zfs.misc.zio_trim.bytes: 0 kstat.zfs.misc.zio_trim.success: 0 kstat.zfs.misc.zio_trim.unsupported: 546 kstat.zfs.misc.zio_trim.failed: 0 That seems to imply that the OS thinks that this drive does not support TRIM, but all the documentation about the 850 drives indicates that they do support TRIM. Indeed, camcontrol reports that TRIM is supported, but (if I'm reading this correctly) not enabled: root@host: camcontrol identify /dev/pass0 pass0: ATA-9 SATA 3.x device pass0: 150.000MB/s transfers, Command Queueing Enabled protocol ATA/ATAPI-9 SATA 3.x device model Samsung SSD 850 EVO 1TB firmware revision EMT01B6Q serial number S21CNXAG526512L WWN 5002538840009228 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 1953525168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queued yes SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify yes no 0/0x0 unload no no general purpose logging yes yes free-fall no no Data Set Management (DSM/TRIM) yes DSM - max 512byte blocks yes 8 DSM - deterministic read no Host Protected Area (HPA) yes no 1953525168/1 HPA - Security no So, my guess is that while the drive supports TRIM, perhaps FreeBSD has disabled TRIM for this drive, perhaps because of the buggy TRIM firmware issues with some drives? I thought those issues were present in the 840 series, but not in the 850 series. Or am I not reading these screens correctly? - -- Tim Gustafson tjg@ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From owner-freebsd-fs@freebsd.org Fri Sep 18 06:55:24 2015 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 3EC629CDFDD for ; Fri, 18 Sep 2015 06:55:24 +0000 (UTC) (envelope-from michael@fuckner.net) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CFE351505 for ; Fri, 18 Sep 2015 06:55:23 +0000 (UTC) (envelope-from michael@fuckner.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1442559319; l=7354; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From: In-Reply-To:Subject:Date; bh=dJi9p3XYepzO79S9vRkijzFAvkwSU4Zf1Y2J5pJSzBo=; b=x7MZz9Yz7WbKunMzyqxXWMLyPRakuSTHVgvjZCuL/SO53BhUz8rYcJ4opZUi/leVgrn /OaVDBwC15sg+aOAH7uxd3PXbsjOyEdLSZx691zjFspm9kvBcy69gNdz2PHHzGMFoQ/9O hmrVcg41vKQZ3jY4WHEhtQDlG0rZdQa7h38= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTYVnoaeJKPgDtkDv5dG8VH78ViobzO X-RZG-CLASS-ID: mo00 Received: from [192.168.1.106] (B925566C.rev.sefiber.dk [185.37.86.108]) by smtp.strato.de (RZmta 37.12 DYNA|AUTH) with ESMTPSA id z05f35r8I6tJw5t (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Fri, 18 Sep 2015 08:55:19 +0200 (CEST) Date: Fri, 18 Sep 2015 08:55:17 +0200 Subject: Re: FreeBSD 10.1 + Samsung 850 EVO + ZFS + TRIM Message-ID: <81c0cff8-2217-4a56-970f-f3964c724156@email.android.com> X-Android-Message-ID: <81c0cff8-2217-4a56-970f-f3964c724156@email.android.com> In-Reply-To: From: Michael Fuckner To: Tim Gustafson Cc: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 06:55:24 -0000 SGksCgpJIGJlbGlldmUgdGhlIFByb2JsZW0gaXMgdGhlIG1maSBjb250cm9sbGVyIHdoaWNoIGFs c28gZG9lcyBSQUlEIGFuZCB0cmltIGNhbiBub3QgYmUgZG9uZSB0aHJvdWdoIG1maS4KCkdvIGZv ciBhbiBIQkEsCiBNaWNoYWVsIQoKQW0gMTguMDkuMjAxNSAwODozNSBzY2hyaWViIFRpbSBHdXN0 YWZzb24gPHRqZ0B1Y3NjLmVkdT46Cj4KPiBIaSwgCj4KPiBJJ3ZlIEdvb2dsZSB0aGlzIGFyb3Vu ZCBhIGJpdCwgYnV0IEkgc2VlbSB0byBiZSBnZXR0aW5nIHNvbWUgCj4gY29uZmxpY3RpbmcgaW5m b3JtYXRpb24gc28gSSdtIGhvcGluZyBJIGNhbiBnZXQgdGhpcyBjbGVhcmVkIHVwIGhlcmUuIAo+ Cj4gSSBoYXZlIGEgc2hpbnkgbmV3IERlbGwgUG93ZXJFZGdlIFI2MzAgd2l0aCBmb3VyIDFUQiBT YW1zdW5nIEVWTyBTU0RzIAo+IGluc3RhbGxlZCBhbmQgY29uZmlndXJlZCBhcyBhIFJBSUQgMCsx IHpwb29sOiAKPgo+IMKgIHBvb2w6IHRhbmsgCj4gc3RhdGU6IE9OTElORSAKPiDCoCBzY2FuOiBz Y3J1YiByZXBhaXJlZCAxNC41SyBpbiAwaDEzbSB3aXRoIDAgZXJyb3JzIG9uIFRodSBTZXAgMTcg MjA6NDc6MTcgMjAxNSAKPiBjb25maWc6IAo+Cj4gwqDCoMKgwqDCoMKgwqAgTkFNRcKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBTVEFURcKgwqDCoMKgIFJFQUQgV1JJVEUgQ0tTVU0gCj4gwqDCoMKg wqDCoMKgwqAgdGFua8KgwqDCoMKgwqDCoMKgwqDCoMKgIE9OTElORcKgwqDCoMKgwqDCoCAwwqDC oMKgwqAgMMKgwqDCoMKgIDAgCj4gwqDCoMKgwqDCoMKgwqDCoMKgIG1pcnJvci0wwqDCoMKgwqDC oMKgIE9OTElORcKgwqDCoMKgwqDCoCAwwqDCoMKgwqAgMMKgwqDCoMKgIDAgCj4gwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBtZmlzeXNwZDBwM8KgIE9OTElORcKgwqDCoMKgwqDCoCAwwqDCoMKgwqAg MMKgwqDCoMKgIDAgCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBtZmlzeXNwZDFwM8KgIE9OTElO RcKgwqDCoMKgwqDCoCAwwqDCoMKgwqAgMMKgwqDCoMKgIDAgCj4gwqDCoMKgwqDCoMKgwqDCoMKg IG1pcnJvci0xwqDCoMKgwqDCoMKgIE9OTElORcKgwqDCoMKgwqDCoCAwwqDCoMKgwqAgMMKgwqDC oMKgIDAgCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBtZmlzeXNwZDNwM8KgIE9OTElORcKgwqDC oMKgwqDCoCAwwqDCoMKgwqAgMMKgwqDCoMKgIDAgCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBt ZmlzeXNwZDJwM8KgIE9OTElORcKgwqDCoMKgwqDCoCAwwqDCoMKgwqAgMMKgwqDCoMKgIDAgCj4K PiBlcnJvcnM6IE5vIGtub3duIGRhdGEgZXJyb3JzIAo+Cj4gSSB3YXMgaW52ZXN0aWdhdGluZyB3 aGV0aGVyIG9yIG5vdCBUUklNIHN1cHBvcnQgd2FzIHdvcmtpbmcsIHNvIEkgZGlkOiAKPgo+IHJv b3RAaG9zdDogc3lzY3RsIC1hIHwgZ3JlcCB0cmltIAo+IHZmcy56ZnMudmRldi50cmltX29uX2lu aXQ6IDEgCj4gdmZzLnpmcy52ZGV2LnRyaW1fbWluX2FjdGl2ZTogMSAKPiB2ZnMuemZzLnZkZXYu dHJpbV9tYXhfYWN0aXZlOiA2NCAKPiB2ZnMuemZzLnZkZXYudHJpbV9tYXhfYnl0ZXM6IDIxNDc0 ODM2NDggCj4gdmZzLnpmcy52ZGV2LnRyaW1fbWF4X3BlbmRpbmc6IDY0IAo+IHZmcy56ZnMudHJp bS5lbmFibGVkOiAxIAo+IHZmcy56ZnMudHJpbS50eGdfZGVsYXk6IDMyIAo+IHZmcy56ZnMudHJp bS50aW1lb3V0OiAzMCAKPiB2ZnMuemZzLnRyaW0ubWF4X2ludGVydmFsOiAxIAo+IGtzdGF0Lnpm cy5taXNjLnppb190cmltLmJ5dGVzOiAwIAo+IGtzdGF0Lnpmcy5taXNjLnppb190cmltLnN1Y2Nl c3M6IDAgCj4ga3N0YXQuemZzLm1pc2MuemlvX3RyaW0udW5zdXBwb3J0ZWQ6IDU0NiAKPiBrc3Rh dC56ZnMubWlzYy56aW9fdHJpbS5mYWlsZWQ6IDAgCj4KPiBUaGF0IHNlZW1zIHRvIGltcGx5IHRo YXQgdGhlIE9TIHRoaW5rcyB0aGF0IHRoaXMgZHJpdmUgZG9lcyBub3QgCj4gc3VwcG9ydCBUUklN LCBidXQgYWxsIHRoZSBkb2N1bWVudGF0aW9uIGFib3V0IHRoZSA4NTAgZHJpdmVzIGluZGljYXRl cyAKPiB0aGF0IHRoZXkgZG8gc3VwcG9ydCBUUklNLsKgIEluZGVlZCwgY2FtY29udHJvbCByZXBv cnRzIHRoYXQgVFJJTSBpcyAKPiBzdXBwb3J0ZWQsIGJ1dCAoaWYgSSdtIHJlYWRpbmcgdGhpcyBj b3JyZWN0bHkpIG5vdCBlbmFibGVkOiAKPgo+IHJvb3RAaG9zdDogY2FtY29udHJvbCBpZGVudGlm eSAvZGV2L3Bhc3MwIAo+IHBhc3MwOiA8U2Ftc3VuZyBTU0QgODUwIEVWTyAxVEIgRU1UMDFCNlE+ IEFUQS05IFNBVEEgMy54IGRldmljZSAKPiBwYXNzMDogMTUwLjAwME1CL3MgdHJhbnNmZXJzLCBD b21tYW5kIFF1ZXVlaW5nIEVuYWJsZWQgCj4KPiBwcm90b2NvbMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIEFUQS9BVEFQSS05IFNBVEEgMy54IAo+IGRldmljZSBtb2RlbMKgwqDCoMKgwqDCoMKg wqDCoCBTYW1zdW5nIFNTRCA4NTAgRVZPIDFUQiAKPiBmaXJtd2FyZSByZXZpc2lvbsKgwqDCoMKg IEVNVDAxQjZRIAo+IHNlcmlhbCBudW1iZXLCoMKgwqDCoMKgwqDCoMKgIFMyMUNOWEFHNTI2NTEy TCAKPiBXV07CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgNTAwMjUzODg0MDAw OTIyOCAKPiBjeWxpbmRlcnPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMTYzODMgCj4gaGVhZHPC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxNiAKPiBzZWN0b3JzL3RyYWNrwqDCoMKg wqDCoMKgwqDCoCA2MyAKPiBzZWN0b3Igc2l6ZcKgwqDCoMKgwqDCoMKgwqDCoMKgIGxvZ2ljYWwg NTEyLCBwaHlzaWNhbCA1MTIsIG9mZnNldCAwIAo+IExCQSBzdXBwb3J0ZWTCoMKgwqDCoMKgwqDC oMKgIDI2ODQzNTQ1NSBzZWN0b3JzIAo+IExCQTQ4IHN1cHBvcnRlZMKgwqDCoMKgwqDCoCAxOTUz NTI1MTY4IHNlY3RvcnMgCj4gUElPIHN1cHBvcnRlZMKgwqDCoMKgwqDCoMKgwqAgUElPNCAKPiBE TUEgc3VwcG9ydGVkwqDCoMKgwqDCoMKgwqDCoCBXRE1BMiBVRE1BNiAKPiBtZWRpYSBSUE3CoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgbm9uLXJvdGF0aW5nIAo+Cj4gRmVhdHVyZcKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBTdXBwb3J0wqAgRW5hYmxlZMKgwqAgVmFs dWXCoMKgwqDCoMKgwqDCoMKgwqDCoCBWZW5kb3IgCj4gcmVhZCBhaGVhZMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgeWVzwqDCoMKgwqDCoCB5ZXMgCj4gd3JpdGUgY2Fj aGXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB5ZXPCoMKgwqDCoMKgIHll cyAKPiBmbHVzaCBjYWNoZcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHll c8KgwqDCoMKgwqAgeWVzIAo+IG92ZXJsYXDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIG5vIAo+IFRhZ2dlZCBDb21tYW5kIFF1ZXVpbmcgKFRDUSnCoMKgIG5v wqDCoMKgwqDCoMKgIG5vIAo+IE5hdGl2ZSBDb21tYW5kIFF1ZXVpbmcgKE5DUSnCoMKgIHllc8Kg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDMyIHRhZ3MgCj4gTkNRIFF1ZXVlIE1hbmFnZW1lbnTC oMKgwqDCoMKgwqDCoMKgwqDCoCBubyAKPiBOQ1EgU3RyZWFtaW5nwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBubyAKPiBSZWNlaXZlICYgU2VuZCBGUERNQSBRdWV1ZWTCoMKgwqAg eWVzIAo+IFNNQVJUwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgeWVzwqDCoMKgwqDCoCB5ZXMgCj4gbWljcm9jb2RlIGRvd25sb2FkwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIHllc8KgwqDCoMKgwqAgeWVzIAo+IHNlY3VyaXR5wqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgeWVzwqDCoMKgwqDCoCBubyAKPiBwb3dlciBt YW5hZ2VtZW50wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB5ZXPCoMKgwqDCoMKgIHllcyAK PiBhZHZhbmNlZCBwb3dlciBtYW5hZ2VtZW50wqDCoMKgwqDCoCBub8KgwqDCoMKgwqDCoCBubyAK PiBhdXRvbWF0aWMgYWNvdXN0aWMgbWFuYWdlbWVudMKgIG5vwqDCoMKgwqDCoMKgIG5vIAo+IG1l ZGlhIHN0YXR1cyBub3RpZmljYXRpb27CoMKgwqDCoMKgIG5vwqDCoMKgwqDCoMKgIG5vIAo+IHBv d2VyLXVwIGluIFN0YW5kYnnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIG5vwqDCoMKgwqDCoMKgIG5v IAo+IHdyaXRlLXJlYWQtdmVyaWZ5wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgeWVzwqDCoMKg wqDCoCBub8KgwqDCoMKgwqAgMC8weDAgCj4gdW5sb2FkwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIG5vwqDCoMKgwqDCoMKgIG5vIAo+IGdlbmVyYWwgcHVy cG9zZSBsb2dnaW5nwqDCoMKgwqDCoMKgwqAgeWVzwqDCoMKgwqDCoCB5ZXMgCj4gZnJlZS1mYWxs wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIG5vwqDCoMKgwqDCoMKg IG5vIAo+IERhdGEgU2V0IE1hbmFnZW1lbnQgKERTTS9UUklNKSB5ZXMgCj4gRFNNIC0gbWF4IDUx MmJ5dGUgYmxvY2tzwqDCoMKgwqDCoMKgIHllc8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDgg Cj4gRFNNIC0gZGV0ZXJtaW5pc3RpYyByZWFkwqDCoMKgwqDCoMKgIG5vIAo+IEhvc3QgUHJvdGVj dGVkIEFyZWEgKEhQQSnCoMKgwqDCoMKgIHllc8KgwqDCoMKgwqAgbm/CoMKgwqDCoMKgIDE5NTM1 MjUxNjgvMSAKPiBIUEEgLSBTZWN1cml0ecKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IG5vIAo+Cj4gU28sIG15IGd1ZXNzIGlzIHRoYXQgd2hpbGUgdGhlIGRyaXZlIHN1cHBvcnRzIFRS SU0sIHBlcmhhcHMgRnJlZUJTRCAKPiBoYXMgZGlzYWJsZWQgVFJJTSBmb3IgdGhpcyBkcml2ZSwg cGVyaGFwcyBiZWNhdXNlIG9mIHRoZSBidWdneSBUUklNIAo+IGZpcm13YXJlIGlzc3VlcyB3aXRo IHNvbWUgZHJpdmVzP8KgIEkgdGhvdWdodCB0aG9zZSBpc3N1ZXMgd2VyZSBwcmVzZW50IAo+IGlu IHRoZSA4NDAgc2VyaWVzLCBidXQgbm90IGluIHRoZSA4NTAgc2VyaWVzLsKgIE9yIGFtIEkgbm90 IHJlYWRpbmcgCj4gdGhlc2Ugc2NyZWVucyBjb3JyZWN0bHk/IAo+Cj4gLSAKPgo+IC0tIAo+Cj4g VGltIEd1c3RhZnNvbiAKPiB0amdAdWNzYy5lZHUgCj4gODMxLTQ1OS01MzU0IAo+IEJhc2tpbiBF bmdpbmVlcmluZywgUm9vbSAzMTNBIAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fIAo+IGZyZWVic2QtZnNAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0IAo+ IGh0dHBzOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWZzIAo+ IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLWZzLXVuc3Vic2NyaWJl QGZyZWVic2Qub3JnIiAK From owner-freebsd-fs@freebsd.org Fri Sep 18 07:35:41 2015 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 195C39CF3A2 for ; Fri, 18 Sep 2015 07:35:41 +0000 (UTC) (envelope-from tjg@ucsc.edu) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 A5EE017EB for ; Fri, 18 Sep 2015 07:35:40 +0000 (UTC) (envelope-from tjg@ucsc.edu) Received: by wiclk2 with SMTP id lk2so19426414wic.1 for ; Fri, 18 Sep 2015 00:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nS13rrsJ1Rg9rsnrjhg+EALBSuzMcKbUMcegTV/EWBc=; b=mldYagSjfKDU92Mt84ykszEXg7LqRT2FwefvA6UJ49ajKLypWm2j6iDhrQ/f7XYWsg PsfWCBRE32ntbZ0TJDf1FZCnt/5cIsFbtjhYOCaVIJaFLoNt8QoNPqzrRhvVtbGWlolM h0ulhJKoeIiSOhOddaPDcGZt4+cdBWw27+YLM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nS13rrsJ1Rg9rsnrjhg+EALBSuzMcKbUMcegTV/EWBc=; b=m4b+3bJc+SNWc5ipPfUZm3kiunXAlu5cGhvwX2rBQQ43j/YOciQA13zCCuEpFejBCs G30/wEAoMPDAR6thankDllizIJ65nJvNQ3w+zuph+o044H43bo0vtJvf93zHPWxlUNkV msc+EzaGQzhnQ7CAMnVQrvLmKHNKYxN2ByzGq2be9XSzRAinU/NHCfPg+RDsxWDU0art B3g371ViGEmKLyBzL2DJ1f7c9sTn068Vto1v1C9Hh8oWt7iwKQ25ehlobPc/Nv35qNHz rnY86of+f7jFolDVSK4ZSlpJJ5q2cKWGuQ2SXdAN+z7/kpCpSfpuDAG/51u/ntt7kQ0M +Njw== X-Gm-Message-State: ALoCoQmnL2sX7MTfQKQSfTNwiTRMDdrzqwMvi3iYAEWL/nV0UB7OgkyqKdRoUtEHouo5K4vF3yk6 MIME-Version: 1.0 X-Received: by 10.194.205.37 with SMTP id ld5mr5805394wjc.14.1442561739125; Fri, 18 Sep 2015 00:35:39 -0700 (PDT) Received: by 10.194.92.209 with HTTP; Fri, 18 Sep 2015 00:35:39 -0700 (PDT) In-Reply-To: <81c0cff8-2217-4a56-970f-f3964c724156@email.android.com> References: <81c0cff8-2217-4a56-970f-f3964c724156@email.android.com> Date: Fri, 18 Sep 2015 00:35:39 -0700 Message-ID: Subject: Re: FreeBSD 10.1 + Samsung 850 EVO + ZFS + TRIM From: Tim Gustafson To: Michael Fuckner Cc: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 07:35:41 -0000 > I believe the Problem is the mfi controller which also does RAID and > trim can not be done through mfi. Even if the mfi controller is configured for pass-through mode? The mfi card is basically configured to be an HBA. -- Tim Gustafson tjg@ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From owner-freebsd-fs@freebsd.org Fri Sep 18 08:39:29 2015 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 1B7D09CE378 for ; Fri, 18 Sep 2015 08:39:29 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 AF8901DD9 for ; Fri, 18 Sep 2015 08:39:27 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by wiclk2 with SMTP id lk2so54722764wic.0 for ; Fri, 18 Sep 2015 01:39:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=xU6u/vQc4iDnvNxTUhbZB96Q3tNmSs5NzGjiQl8V+T4=; b=LeU2UiAuEvDoN30bjxdqCgtg7bXxPWhhVHno36f/qw0ZlrDFUT9nHUQhIRQvGTIp6K vn6Yc3zpV8y1lAQCeehuW3btx6RnpfjHeWhvz0k2/G7M10sJ6ZLwC1rhkVyyx8kiUMRR CJZKFGOtd/yaTah4rUzuYwKqAp/InyU2f4UNCJvu2RG7UP3uVraJT5S+aa2KcYaEeWgU Js2Vh0fXPSK9/fsyE24OEG0kjCHkDe0J2bqrDfO4GtOE5TTtGWFmNYwkznVJX/DPstPu H27cRWIMiFPvUkFZ2ZAYmgiz9fDdN6D7qOzaDjIUIB+ZFc9VIfM4v24eQ3Pd/ft1lc+2 nshQ== X-Gm-Message-State: ALoCoQmCsCgP0YfjRxVkrGez0yktDl82wVM+EUqD7jo0HK43Y4EGXo9sc4zkmmlgt/hJ96cFFH9A X-Received: by 10.180.9.162 with SMTP id a2mr13883574wib.95.1442565566120; Fri, 18 Sep 2015 01:39:26 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by smtp.gmail.com with ESMTPSA id t7sm936249wje.13.2015.09.18.01.39.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2015 01:39:24 -0700 (PDT) Subject: Re: FreeBSD 10.1 + Samsung 850 EVO + ZFS + TRIM To: freebsd-fs@freebsd.org References: From: Steven Hartland Message-ID: <55FBCDB5.9060403@multiplay.co.uk> Date: Fri, 18 Sep 2015 09:39:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 08:39:29 -0000 You're explicitly doing pass0 there does that mean your not using direct attach and have some sort of RAID running on the mfi? Only CAM da and ada know how to perform TRIM requests, so if your not using either then that would be correct. What's camcontrol devlist look like? Ideally you shouldn't use a RAID based controller, a HBA will give you better performance which uses mps driver. On 18/09/2015 07:35, Tim Gustafson wrote: > Hi, > > I've Google this around a bit, but I seem to be getting some > conflicting information so I'm hoping I can get this cleared up here. > > I have a shiny new Dell PowerEdge R630 with four 1TB Samsung EVO SSDs > installed and configured as a RAID 0+1 zpool: > > pool: tank > state: ONLINE > scan: scrub repaired 14.5K in 0h13m with 0 errors on Thu Sep 17 20:47:17 2015 > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > mfisyspd0p3 ONLINE 0 0 0 > mfisyspd1p3 ONLINE 0 0 0 > mirror-1 ONLINE 0 0 0 > mfisyspd3p3 ONLINE 0 0 0 > mfisyspd2p3 ONLINE 0 0 0 > > errors: No known data errors > > I was investigating whether or not TRIM support was working, so I did: > > root@host: sysctl -a | grep trim > vfs.zfs.vdev.trim_on_init: 1 > vfs.zfs.vdev.trim_min_active: 1 > vfs.zfs.vdev.trim_max_active: 64 > vfs.zfs.vdev.trim_max_bytes: 2147483648 > vfs.zfs.vdev.trim_max_pending: 64 > vfs.zfs.trim.enabled: 1 > vfs.zfs.trim.txg_delay: 32 > vfs.zfs.trim.timeout: 30 > vfs.zfs.trim.max_interval: 1 > kstat.zfs.misc.zio_trim.bytes: 0 > kstat.zfs.misc.zio_trim.success: 0 > kstat.zfs.misc.zio_trim.unsupported: 546 > kstat.zfs.misc.zio_trim.failed: 0 > > That seems to imply that the OS thinks that this drive does not > support TRIM, but all the documentation about the 850 drives indicates > that they do support TRIM. Indeed, camcontrol reports that TRIM is > supported, but (if I'm reading this correctly) not enabled: > > root@host: camcontrol identify /dev/pass0 > pass0: ATA-9 SATA 3.x device > pass0: 150.000MB/s transfers, Command Queueing Enabled > > protocol ATA/ATAPI-9 SATA 3.x > device model Samsung SSD 850 EVO 1TB > firmware revision EMT01B6Q > serial number S21CNXAG526512L > WWN 5002538840009228 > cylinders 16383 > heads 16 > sectors/track 63 > sector size logical 512, physical 512, offset 0 > LBA supported 268435455 sectors > LBA48 supported 1953525168 sectors > PIO supported PIO4 > DMA supported WDMA2 UDMA6 > media RPM non-rotating > > Feature Support Enabled Value Vendor > read ahead yes yes > write cache yes yes > flush cache yes yes > overlap no > Tagged Command Queuing (TCQ) no no > Native Command Queuing (NCQ) yes 32 tags > NCQ Queue Management no > NCQ Streaming no > Receive & Send FPDMA Queued yes > SMART yes yes > microcode download yes yes > security yes no > power management yes yes > advanced power management no no > automatic acoustic management no no > media status notification no no > power-up in Standby no no > write-read-verify yes no 0/0x0 > unload no no > general purpose logging yes yes > free-fall no no > Data Set Management (DSM/TRIM) yes > DSM - max 512byte blocks yes 8 > DSM - deterministic read no > Host Protected Area (HPA) yes no 1953525168/1 > HPA - Security no > > So, my guess is that while the drive supports TRIM, perhaps FreeBSD > has disabled TRIM for this drive, perhaps because of the buggy TRIM > firmware issues with some drives? I thought those issues were present > in the 840 series, but not in the 850 series. Or am I not reading > these screens correctly? > > - > From owner-freebsd-fs@freebsd.org Fri Sep 18 23:49:01 2015 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 9A02E9D0C39 for ; Fri, 18 Sep 2015 23:49:01 +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 863FF18FC for ; Fri, 18 Sep 2015 23:49:01 +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 t8INn1xf086913 for ; Fri, 18 Sep 2015 23:49:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 203185] mountd is exposing parent directories [on zfs mount?] that it should not be Date: Fri, 18 Sep 2015 23:49:01 +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 Only Me X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 23:49:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203185 Rick Macklem changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress --- Comment #2 from Rick Macklem --- The -alldirs flag allows all directories within the file system to be mounted. If the directory specified in the path isn't the root of the file system, then that will include directory paths above the directory. Note that "showmount" uses the Mount protocol and there is no way to express "-alldirs" for it, so showmount can only show the path in the /etc/exports line. Here is the snippet from "man exports": The second is to specify the pathname of the root of the file system fol- lowed by the -alldir flag; this form allows the host(s) to mount at any point within the file system, including regular files if the -r option is used on mountd(8). Although the man pages says "root of the file system", mountd does not enforce this. I am assuming that /home/ngie is the same file system as /home/ngie/XXX. Please close this bug unless you still feel that mountd is not providing the semantics expressed in "man exports" above. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sat Sep 19 09:53:16 2015 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 13C8DA030F3 for ; Sat, 19 Sep 2015 09:53:16 +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 00BF713DC for ; Sat, 19 Sep 2015 09:53:16 +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 t8J9rFef073910 for ; Sat, 19 Sep 2015 09:53:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 203201] on zfs extattr behaviour broken after unlink Date: Sat, 19 Sep 2015 09:53:16 +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: avg@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 09:53:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203201 Andriy Gapon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sat Sep 19 09:56:37 2015 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 E812CA032EF for ; Sat, 19 Sep 2015 09: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 CCC98154A for ; Sat, 19 Sep 2015 09: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 t8J9ubMQ076935 for ; Sat, 19 Sep 2015 09:56:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 203201] on zfs extattr behaviour broken after unlink Date: Sat, 19 Sep 2015 09: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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: justin@specialbusservice.com X-Bugzilla-Status: Open X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 09:56:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203201 --- Comment #7 from justin@specialbusservice.com --- Created attachment 161184 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=161184&action=edit test case when attribute exists Yes, when the attribute exists you get the same ENOENT error, see this test case. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sat Sep 19 11:56:25 2015 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 02FCFA0330C for ; Sat, 19 Sep 2015 11:56:25 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 7B06D1C59 for ; Sat, 19 Sep 2015 11:56:24 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by lbbvu2 with SMTP id vu2so35338168lbb.0 for ; Sat, 19 Sep 2015 04:56:21 -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:content-type; bh=Fq8SHP54MBhnvIAWUt3JFKpEq7OrebePj8rrYlQYE4Q=; b=MyXr0GNv6akG8psCmVw3TBYfms0xTBoNwoysJ5l0RixfGrS2hZy2UhqFpQucbUXgVN WmmRirX4MCRxhVxiXlapqno8iz16cHF7BTskVQT1Vh9IPyUY800ECtsiIDjA6U/i2Ph6 vbk4CfrhTGR4cLeeldQ0ZKLaFG3uiPyUFnZv3cqW1MA5oJ7RdDyf+fe7k6KpUBMxgtOz FShv3kaojJoGZ8mLCgFFSM96y7qT/aIuDzQGOfUNVYqcYrX9siwFHb5IUnjm24gKcq5u DyLU48FI3XKWMyhlQ+APfNYDnanpNvHLeM+CXnRv9SwFll467MpSZqIprcvtpSnL2eeD RdQA== MIME-Version: 1.0 X-Received: by 10.112.155.195 with SMTP id vy3mr4820351lbb.9.1442663781442; Sat, 19 Sep 2015 04:56:21 -0700 (PDT) Received: by 10.112.180.2 with HTTP; Sat, 19 Sep 2015 04:56:21 -0700 (PDT) Received: by 10.112.180.2 with HTTP; Sat, 19 Sep 2015 04:56:21 -0700 (PDT) Date: Sat, 19 Sep 2015 14:56:21 +0300 Message-ID: Subject: ZFS cpu requirements, with/out compression and/or dedup From: Sami Halabi To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 11:56:25 -0000 Hi everyone, I've been searching the documentation, wiki.. etc. but found no rule of thumb to CPU requirements to run ZFS fs. for memory there are few rules according to using dedup or not. rules of thumb I concluded are so far: 1. use compression lz4. 2. use checksum. 3. disable atime. from what i read the status of dedup is not that clear and seems there are bugs and better to avoid it? so according to 1-3 above what cpu requirements i need? is ATOM cpu like supermicro c2750/3/5/8 enough to run system of 20TB /40TB with 1-3 above? if dedup IS enabled would it still work fine? Thanks in advance, Sami halabi From owner-freebsd-fs@freebsd.org Sat Sep 19 14:08:38 2015 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 A2AE9A02E52 for ; Sat, 19 Sep 2015 14:08:38 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 478471F2E for ; Sat, 19 Sep 2015 14:08:37 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id t8JE4moU015486; Sat, 19 Sep 2015 09:04:48 -0500 (CDT) Date: Sat, 19 Sep 2015 09:04:48 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Sami Halabi cc: freebsd-fs@freebsd.org Subject: Re: ZFS cpu requirements, with/out compression and/or dedup In-Reply-To: Message-ID: References: User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Sat, 19 Sep 2015 09:04:49 -0500 (CDT) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 14:08:38 -0000 On Sat, 19 Sep 2015, Sami Halabi wrote: > Hi everyone, > I've been searching the documentation, wiki.. etc. but found no rule of > thumb to CPU requirements to run ZFS fs. for memory there are few rules > according to using dedup or not. > > rules of thumb I concluded are so far: > 1. use compression lz4. > 2. use checksum. > 3. disable atime. > > from what i read the status of dedup is not that clear and seems there are > bugs and better to avoid it? I am not so sure about dedup bugs. Usually the problem encountered with dedup is unrealistic expectations about how it will behave. Dedup requires a large amount of RAM and/or L2ARC device which are appropriately sized for the amount of storage and the amount of redundancy encountered. The problem typically encountered is that things work "fine" with dedup until one day they do not and when they do not, it is like going off a cliff. Don't enable dedup unless you have carefully researched it, decided that its value outweighs its cost, and make sure that you have enough RAM or SSD-based L2ARC (preferably RAM) so that the tables it needs are all readily available without accessing rotating media. Depending on what you were planning to use dedup for, there may be other zfs tricks (e.g. cloning) which are amost as effective, but without the risks. > so according to 1-3 above what cpu requirements i need? is ATOM cpu like > supermicro c2750/3/5/8 enough to run system of 20TB /40TB with 1-3 above? > if dedup IS enabled would it still work fine? CPU usage is rarely a problem for zfs except for when compression is involved. Lz4 is supposed to be CPU-efficient on Intel CPUs. Don't use gzip compression if you don't have a powerful CPU. Compression can be changed at any time, although a given file will remain compressed with the compression setting in effect when it was created. CPU use is driven by I/O requirements and selected compression algorithms and not by the size of the storage pool. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@freebsd.org Sat Sep 19 17:24:03 2015 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 BE3E69CEF3F for ; Sat, 19 Sep 2015 17:24:03 +0000 (UTC) (envelope-from quartz@sneakertech.com) Received: from douhisi.pair.com (douhisi.pair.com [209.68.5.179]) (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 9F8F31E61 for ; Sat, 19 Sep 2015 17:24:03 +0000 (UTC) (envelope-from quartz@sneakertech.com) Received: from [10.2.2.1] (pool-173-48-121-235.bstnma.fios.verizon.net [173.48.121.235]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by douhisi.pair.com (Postfix) with ESMTPSA id 4C0EE3F778 for ; Sat, 19 Sep 2015 13:23:56 -0400 (EDT) Message-ID: <55FD9A2B.8060207@sneakertech.com> Date: Sat, 19 Sep 2015 13:23:55 -0400 From: Quartz MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: ZFS cpu requirements, with/out compression and/or dedup References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 17:24:03 -0000 > from what i read the status of dedup is not that clear and seems there are > bugs and better to avoid it? There aren't [m]any legitimate bugs with dedup, the problem is that it consumes metric assloads of ram, on the order of 2-5GB per TB of disk space (this is in addition to whatever the ARC eats). If you run out of ram performance jumps off a cliff. It's also 'permanent' in the sense that you have to turn it on with the creation of a dataset and can't disable it without nuking said dataset. The issue of "bugs" are probably from people experiencing file corruption because they enabled only block checksums without also exact verification, and don't understand hash collisions. > so according to 1-3 above what cpu requirements i need? Not much. CPU only really takes a hit when you turn on gzip compression and crank it up to high levels. > supermicro c2750/3/5/8 enough to run system of 20TB /40TB with 1-3 above? > if dedup IS enabled would it still work fine? Probably not. That board only supports up to 64GB of ram. 20TB of disk space with dedup will require like 50-100 GB of ram, and 40TB will need a good 90GB at least.