From owner-freebsd-fs@FreeBSD.ORG Sun Feb 15 21:00:19 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1A86244 for ; Sun, 15 Feb 2015 21:00:19 +0000 (UTC) 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 C73CE774 for ; Sun, 15 Feb 2015 21:00:19 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t1FL0Jxm014693 for ; Sun, 15 Feb 2015 21:00:19 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201502152100.t1FL0Jxm014693@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, 15 Feb 2015 21:00:19 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 21:00:20 -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 Feb 15 21:26:31 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79A52C71 for ; Sun, 15 Feb 2015 21:26:31 +0000 (UTC) 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 5C6D0A4C for ; Sun, 15 Feb 2015 21:26:31 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t1FLQVj0098470 for ; Sun, 15 Feb 2015 21:26:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 194586] [zfs] kernel panic when running zpool/add/option-f_size_mismatch.t Date: Sun, 15 Feb 2015 21:26:31 +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: kerryfbrosius@yahoo.com 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: 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 21:26:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194586 --- Comment #2 from Kerry Bfousius --- "[Espncricinfo] Ireland vs West indies Live.. http://www.reddit.com/r/braidpkb/comments/2vzttv/" "[Espncricinfo] Ireland vs West indies Live.. http://www.reddit.com/r/braidpkb/comments/2vzttv/" "[Espncricinfo] Ireland vs West indies Live.. http://www.reddit.com/r/braidpkb/comments/2vzttv/" -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 16 09:08:20 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B37A556 for ; Mon, 16 Feb 2015 09:08:20 +0000 (UTC) Received: from COL004-OMC4S2.hotmail.com (col004-omc4s2.hotmail.com [65.55.34.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD8E47F6 for ; Mon, 16 Feb 2015 09:08:19 +0000 (UTC) Received: from COL128-W74 ([65.55.34.200]) by COL004-OMC4S2.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 16 Feb 2015 01:07:13 -0800 X-TMN: [E2Wrxju6cURQjnz3pW62VFTqKbBIPX+8Odc25lJrKgY=] X-Originating-Email: [zhangxia3@hotmail.com] Message-ID: From: zx zx To: "freebsd-fs@freebsd.org" Subject: About Filesystem freeze/thaw in freebsd Date: Mon, 16 Feb 2015 01:07:12 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 16 Feb 2015 09:07:13.0157 (UTC) FILETIME=[F3D02B50:01D049C7] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 09:08:20 -0000 Hi=2C I am experimenting to do a live backup of FreeBSD VM. = Question is do we have freeze/thaw interfaces in FreeBSD? I searched a lot = in web and freebsd source code=2C just could not find the right interface. = As I know that in linux:VxFS provides ioctl interfaces to app= lication programs to freeze and thaw VxFS file systems. The interfaces are = VX_FREEZE=2C VX_FREEZE_ALL=2C and VX_THAW.About Freeze and thaw Freezing a = file system temporarily blocks all I/O operations to a file system and then= performs a sync on the file system. Current operations are completed and t= he file system is synchronized to disk. Freezing a file system is a necessa= ry step for obtaining a stable and consistent image of the file system at t= he volume level. Consistent volume-level file system images can be obtained= and used with a file system snapshot tool. The freeze operation flushes al= l buffers and pages in the file system cache that contain dirty metadata an= d user data. The operation then suspends any new activity on the file syste= m until the file system is thawed. Any help would be appreciate= d=2C thanks a lot! Andy Zhang = From owner-freebsd-fs@FreeBSD.ORG Mon Feb 16 09:32:19 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27B4DE23 for ; Mon, 16 Feb 2015 09:32:19 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C1C8BAD6 for ; Mon, 16 Feb 2015 09:32:18 +0000 (UTC) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.1/8.15.1) with ESMTPSA id t1G9VwmT068557 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 16 Feb 2015 09:32:13 GMT (envelope-from matthew@freebsd.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=freebsd.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk t1G9VwmT068557 Authentication-Results: smtp.infracaninophile.co.uk/t1G9VwmT068557; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Message-ID: <54E1B90E.8050101@freebsd.org> Date: Mon, 16 Feb 2015 09:31:58 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: About Filesystem freeze/thaw in freebsd References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aACxa3nfAX3n4xcEClw7HhAUUJ7LiAVkc" X-Virus-Scanned: clamav-milter 0.98.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 09:32:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aACxa3nfAX3n4xcEClw7HhAUUJ7LiAVkc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/16/15 09:07, zx zx wrote: > Hi, I am experimenting to do a live backup of FreeBSD > VM. Question is do we have freeze/thaw interfaces in FreeBSD? I > searched a lot in web and freebsd source code, just could not find > the right interface. As I know that in linux:VxFS > provides ioctl interfaces to application programs to freeze and thaw > VxFS file systems. The interfaces are VX_FREEZE, VX_FREEZE_ALL, and > VX_THAW.About Freeze and thaw Freezing a file system temporarily > blocks all I/O operations to a file system and then performs a sync > on the file system. Current operations are completed and the file > system is synchronized to disk. Freezing a file system is a necessary > step for obtaining a stable and consistent image of the file system > at the volume level. Consistent volume-level file system images can > be obtained and used with a file system snapshot tool. The freeze > operation flushes all buffers and pages in the file system cache that > contain dirty metadata and user data. The operation then suspends any > new activity on the file system until the file system is thawed. > Any help would be appreciated, thanks a lot! Andy Zhang What you want is snapshotting. You can create a snapshot of UFS or ZFS filesystems, mount the snapshot and then back it up without needing to worry about the filesystem changing while you're trying to back it up. See mksnap_ffs(8) and the 'snapshot' entry in zfs(8) The snapshot is mounted separately from the actual filesystem which can carry on with normal activities in the mean time. Snapshotting functionality is built into dump(8) for UFS filesystems (See the -L flag in that man page) or you can use zfs send / recv to dump filesystems to tape, which implies use of snapshots. Cheers, Matthew --aACxa3nfAX3n4xcEClw7HhAUUJ7LiAVkc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJU4bkOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnnlYP/jHvdmSD/ddTW5OiwY191rKw knTidCezM7HvN+k68CkJ8Zi3Hspt0OWH+2+LCFTENDSgYVn+YsLWd5Sqimu7YJSP 5yyzYWBd8ubPb3cb1NClmwWrojTJtPKhY5xgOofZmjsMPqPcZVXZ8rlVk7kOgq5B O2XizNMp4fT4O0mOU7AFmKmTug05b4XM73nYSDpho9NIuFk0IM44GpcFwojhPSn9 9LVVwA//flwjd56O7sd2cWpuNJkWmX6YX/8Jzp4hyfd4YqyCQ7J6qAJqRE/ZKF32 pWTcrl6xiGNJlrwzc/Ija4iq43yS9xwlVR5SXHZBCn4kgGJ3my6ceISoZa1l+pvr W2QV9SQyiv7OQlSf6eHGsT6zDqmerjq6PwTnSLU4wcl5qpM4/wTp8zQJ2BWMkVr7 FrMf93piy7TVaQHg9tpi5LRyOMEbVN6NpH/YSLR6ThYGe1APDDafrQkgGeQZDD+F 3LerLYQ/prvhi/ApeuYtgG/raOsPajTHSV2qb3EFEIE0vlpFYF5gWNUcRrwjFvfw OiQbVKT6lbRPaW/h/jVjcaWzFOwfsDIos/15L3f4berpt81HpnXNumPAVVqRgaJa 5ismFrvS3F6muI+mDGkiE9GCdHbyAlHm/hY08w/mTX76HpFo+XRPCJbHDqHQlWFH pj2w7zXrEY9F10Msxtdl =11OF -----END PGP SIGNATURE----- --aACxa3nfAX3n4xcEClw7HhAUUJ7LiAVkc-- From owner-freebsd-fs@FreeBSD.ORG Mon Feb 16 09:54:16 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48A9A932; Mon, 16 Feb 2015 09:54:16 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 C7614D47; Mon, 16 Feb 2015 09:54:15 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t1G9sALY078481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2015 11:54:11 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t1G9sALY078481 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t1G9sAm0078480; Mon, 16 Feb 2015 11:54:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 16 Feb 2015 11:54:10 +0200 From: Konstantin Belousov To: Matthew Seaman Subject: Re: About Filesystem freeze/thaw in freebsd Message-ID: <20150216095410.GH34251@kib.kiev.ua> References: <54E1B90E.8050101@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E1B90E.8050101@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 09:54:16 -0000 On Mon, Feb 16, 2015 at 09:31:58AM +0000, Matthew Seaman wrote: > On 02/16/15 09:07, zx zx wrote: > > Hi, I am experimenting to do a live backup of FreeBSD > > VM. Question is do we have freeze/thaw interfaces in FreeBSD? I > > searched a lot in web and freebsd source code, just could not find > > the right interface. As I know that in linux:VxFS > > provides ioctl interfaces to application programs to freeze and thaw > > VxFS file systems. The interfaces are VX_FREEZE, VX_FREEZE_ALL, and > > VX_THAW.About Freeze and thaw Freezing a file system temporarily > > blocks all I/O operations to a file system and then performs a sync > > on the file system. Current operations are completed and the file > > system is synchronized to disk. Freezing a file system is a necessary > > step for obtaining a stable and consistent image of the file system > > at the volume level. Consistent volume-level file system images can > > be obtained and used with a file system snapshot tool. The freeze > > operation flushes all buffers and pages in the file system cache that > > contain dirty metadata and user data. The operation then suspends any > > new activity on the file system until the file system is thawed. > > Any help would be appreciated, thanks a lot! Andy Zhang > > What you want is snapshotting. You can create a snapshot of UFS or ZFS > filesystems, mount the snapshot and then back it up without needing to > worry about the filesystem changing while you're trying to back it up. > > See mksnap_ffs(8) and the 'snapshot' entry in zfs(8) > > The snapshot is mounted separately from the actual filesystem which can > carry on with normal activities in the mean time. > > Snapshotting functionality is built into dump(8) for UFS filesystems > (See the -L flag in that man page) or you can use zfs send / recv to > dump filesystems to tape, which implies use of snapshots. Snapshot is different functionality from what the OP asked. Exactly requested feature is provided by UFSSUSPEND/UFSRESUME ioctls on the /dev/ufssuspend, for UFS volumes. You should consult the code to see how to use them. I suspect that the similar feature exists for ZFS, but I do not know where to start looking. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 16 16:47:18 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2903C4D9; Mon, 16 Feb 2015 16:47:18 +0000 (UTC) Received: from smtp2.bway.net (smtp2.v6.bway.net [IPv6:2607:d300:1::28]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC59429; Mon, 16 Feb 2015 16:47:17 +0000 (UTC) Received: from [10.3.2.41] (foon.sporktines.com [96.57.144.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: spork@bway.net) by smtp2.bway.net (Postfix) with ESMTPSA id 5818D95851; Mon, 16 Feb 2015 11:47:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bway.net; s=mail; t=1424105227; bh=W0RXd8y5FOcHTX0hVZ2JDVPyfg369TQf6j9lVcIG/Po=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Gyv1wYTl2n8vsDEubE63u5snyb2RouzoT1Nf+A385R2pfyDzvrW687V3pg6TDqoWk RjW6L9Nop8D4rKsHFTzRPSBSC+szV0D6pO2mZwfFsPU/6eEw+9zzsZGYTqFwFazMzM l3A6qjx9N4zvkw1rEp252XutCx9C4eFQvqUunU2g= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: About Filesystem freeze/thaw in freebsd From: Charles Sprickman In-Reply-To: <20150216095410.GH34251@kib.kiev.ua> Date: Mon, 16 Feb 2015 11:47:06 -0500 Content-Transfer-Encoding: 7bit Message-Id: <16F552EF-83A2-496B-A7ED-7B62B78D666B@bway.net> References: <54E1B90E.8050101@freebsd.org> <20150216095410.GH34251@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-fs@freebsd.org, Matthew Seaman X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 16:47:18 -0000 On Feb 16, 2015, at 4:54 AM, Konstantin Belousov wrote: > On Mon, Feb 16, 2015 at 09:31:58AM +0000, Matthew Seaman wrote: >> On 02/16/15 09:07, zx zx wrote: >>> Hi, I am experimenting to do a live backup of FreeBSD >>> VM. Question is do we have freeze/thaw interfaces in FreeBSD? I >>> searched a lot in web and freebsd source code, just could not find >>> the right interface. As I know that in linux:VxFS >>> provides ioctl interfaces to application programs to freeze and thaw >>> VxFS file systems. The interfaces are VX_FREEZE, VX_FREEZE_ALL, and >>> VX_THAW.About Freeze and thaw Freezing a file system temporarily >>> blocks all I/O operations to a file system and then performs a sync >>> on the file system. Current operations are completed and the file >>> system is synchronized to disk. Freezing a file system is a necessary >>> step for obtaining a stable and consistent image of the file system >>> at the volume level. Consistent volume-level file system images can >>> be obtained and used with a file system snapshot tool. The freeze >>> operation flushes all buffers and pages in the file system cache that >>> contain dirty metadata and user data. The operation then suspends any >>> new activity on the file system until the file system is thawed. >>> Any help would be appreciated, thanks a lot! Andy Zhang >> >> What you want is snapshotting. You can create a snapshot of UFS or ZFS >> filesystems, mount the snapshot and then back it up without needing to >> worry about the filesystem changing while you're trying to back it up. >> >> See mksnap_ffs(8) and the 'snapshot' entry in zfs(8) >> >> The snapshot is mounted separately from the actual filesystem which can >> carry on with normal activities in the mean time. >> >> Snapshotting functionality is built into dump(8) for UFS filesystems >> (See the -L flag in that man page) or you can use zfs send / recv to >> dump filesystems to tape, which implies use of snapshots. > > Snapshot is different functionality from what the OP asked. > Exactly requested feature is provided by UFSSUSPEND/UFSRESUME ioctls > on the /dev/ufssuspend, for UFS volumes. You should consult the code > to see how to use them. Do the VMWare tools currently implement this? VMWare doesnt complain when making snapshots, but I never found a way to verify its actually working. How about Xen and popular Xen variations like Amazon and Digital Ocean? Thanks, Charles > > I suspect that the similar feature exists for ZFS, but I do not know > where to start looking. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 16 19:38:58 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87BB38B8 for ; Mon, 16 Feb 2015 19:38:58 +0000 (UTC) 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 Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 59B0361E for ; Mon, 16 Feb 2015 19:38:57 +0000 (UTC) X-ASG-Debug-ID: 1424115537-08ca04364f32ed0001-3nHGF7 Received: from mail.iXsystems.com ([10.2.55.1]) by barracuda.ixsystems.com with ESMTP id nEVMxSd2e7KHvism (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 16 Feb 2015 11:38:57 -0800 (PST) X-Barracuda-Envelope-From: jkh@ixsystems.com X-Barracuda-RBL-Trusted-Forwarder: 10.2.55.1 X-ASG-Whitelist: Client Received: from [10.8.0.50] (unknown [10.8.0.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 5E36B8CFAE; Mon, 16 Feb 2015 11:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1424115537; bh=OB+oDTwUhRmdqinx46KYtEgNOAmr6qeNHHqumFVq0nA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=HL6z6UbwgDlF49VM9plBWTwzmj4S29Az6nQElLebnP3Mwfv1/7UEZUDHtraNMa6Ql EpA66MIzQZbMOjs4Sm3TQQHqEBLNWPpkn2vo7c7foEwMbNMDClKCzdwU8FaFVPpxpl vmPA01XSGLnZQ16lI9jHkUooQLB+TApAAEDRkZbE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2081\)) Subject: Re: About Filesystem freeze/thaw in freebsd From: Jordan Hubbard X-ASG-Orig-Subj: Re: About Filesystem freeze/thaw in freebsd In-Reply-To: <16F552EF-83A2-496B-A7ED-7B62B78D666B@bway.net> Date: Mon, 16 Feb 2015 11:38:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <70C2BC1A-3233-4631-A53D-F55FCDF3827F@ixsystems.com> References: <54E1B90E.8050101@freebsd.org> <20150216095410.GH34251@kib.kiev.ua> <16F552EF-83A2-496B-A7ED-7B62B78D666B@bway.net> To: Charles Sprickman X-Mailer: Apple Mail (2.2081) X-Barracuda-Connect: UNKNOWN[10.2.55.1] X-Barracuda-Start-Time: 1424115537 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 Cc: freebsd-fs@freebsd.org, Matthew Seaman X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 19:38:58 -0000 > On Feb 16, 2015, at 8:47 AM, Charles Sprickman wrote: >=20 > Do the VMWare tools currently implement this? >=20 > VMWare doesnt complain when making snapshots, but I never found a > way to verify its actually working. You can=E2=80=99t do it that way with VMWare, at least not without some = extra moving parts, since VMWare=E2=80=99s notion of snapshots and the = host=E2=80=99s notion (UFS or ZFS, it matters not) are entirely = disparate. VMWare has some APIs that the host can optionally support = (FreeBSD does not) to coordinate snapshots but other than that, again, = no joy. FreeNAS provides a =E2=80=9Ccoordinated snapshot=E2=80=9D mechanism with = VMWare that basically calls out to VMWare (using its REST API) to = snapshot all of the VMs on a given dataset, then takes a ZFS snapshot = which encapsulates those VMWare snapshots, and destroys the VMWare = snapshots afterwards (since they=E2=80=99re no longer useful). It=E2=80=99= s a little ghetto, but a whole lot better than purely uncoordinated = snapshots where you have no idea if the VM is in a stable (known) state = when you take the ZFS snapshot. > How about Xen and popular Xen variations like Amazon and Digital = Ocean? Even less well understood / supported. - Jordan From owner-freebsd-fs@FreeBSD.ORG Mon Feb 16 20:48:45 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99E1A730; Mon, 16 Feb 2015 20:48:45 +0000 (UTC) Received: from sasl.smtp.pobox.com (pb-sasl1.int.icgroup.com [208.72.237.25]) by mx1.freebsd.org (Postfix) with ESMTP id 54D2ADE7; Mon, 16 Feb 2015 20:48:44 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 2C3E034E82; Mon, 16 Feb 2015 15:48:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date :message-id:from:to:cc:subject:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=sasl; bh=ispXgz3D8/0SDE1P8iC/lSCvJt8=; b=Us2XOjpg6/QZ388/W+9y3bb9+VYN LEwxYn//OUhKE83ZWfNoygVNFxoxa/+basOhDZ/mDBc524rk7A2t8lhTpJoam6zK G2GmXKEfa6vASvkaEehrUpBgoYS6lcbtgtXvwaoPTbzjND7B8aGyi5Ar4PIIiTNl KiNANZ6nmxW9bvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:message-id :from:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=SW5tWk Ao4+EpRqWfR+5owSzcXNAfvLMSoIoTX7NIifXG1eeReyMFVCXoF4DQP7th03MJKv niBEk446s3PqlM2NU/ShQOw/A/ZdSqb8MhJJbYHIAZf7PO1PQc5kYjGwZOCgwtaA WMeSSnaFVtdXSx4FAuwiYuLPqPFas0JtpdnqA= Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 200C534E80; Mon, 16 Feb 2015 15:48:38 -0500 (EST) Received: from bmach.nederware.nl (unknown [27.252.214.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id 8D59F34E7F; Mon, 16 Feb 2015 15:48:36 -0500 (EST) Received: from quadrio.nederware.nl (quadrio.nederware.nl [192.168.33.13]) by bmach.nederware.nl (Postfix) with ESMTP id 33D472ED5D; Tue, 17 Feb 2015 09:48:34 +1300 (NZDT) Received: from quadrio.nederware.nl (localhost [127.0.0.1]) by quadrio.nederware.nl (Postfix) with ESMTP id E2B2F8006490; Tue, 17 Feb 2015 09:48:33 +1300 (NZDT) Date: Tue, 17 Feb 2015 09:48:33 +1300 Message-ID: <87a90dshum.wl-berend@pobox.com> From: Berend de Boer To: Konstantin Belousov Subject: Re: About Filesystem freeze/thaw in freebsd In-Reply-To: <20150216095410.GH34251@kib.kiev.ua> References: <54E1B90E.8050101@freebsd.org> <20150216095410.GH34251@kib.kiev.ua> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.3 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Tue_Feb_17_09:48:33_2015-1"; micalg=pgp-sha256; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 2DC0DFB4-B61D-11E4-9BD4-8FDD009B7A5A-48001098!pb-sasl1.pobox.com Cc: freebsd-fs@freebsd.org, Matthew Seaman X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 20:48:45 -0000 --pgp-sign-Multipart_Tue_Feb_17_09:48:33_2015-1 Content-Type: text/plain; format=flowed; charset=US-ASCII >>>>> "Konstantin" == Konstantin Belousov writes: Konstantin> I suspect that the similar feature exists for ZFS, but Konstantin> I do not know where to start looking. zfs doesn't have this, it has been mentioned a few times in various mailing lists (by me for example), as it's very useful to have on Amazon EC2. -- All the best, Berend de Boer --pgp-sign-Multipart_Tue_Feb_17_09:48:33_2015-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP Digital Signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAABCAAGBQJU4lehAAoJEKOfeD48G3g5U0UQAKSnjDdIP56xcqDn22l0o54F FG8BVyb2APCSSHaaGBmnvTpzd2GX2/bW5ccRQ/WN6E9Ngewh3eDFgOKz8IP3muVJ Oe+PdPVLMc6EcxHDNLSX/l7A142QatJw2rITExmUdEavExbzhlOgs2uGoXw5eIiC W7S9B3uFLTFAVFDuAzFRHBIr8PRWjTmSE7q2ZyBDOf1TlLEpyTwWCtGHuYEtthvH TZ7sIVhhU6QkKL1oePSz7aVXDIJ4eCzxvLlQ7WChAw87veja/YwnBzjBSZtLAV4q vSj97kEPCT1t/ydzG9S3wvEqONQRkxX86lZF6rOF+gPTjTTNLfiR7OvnCGz2Dxp5 EEaq6If6KECWfH4pbuxge1vN0k05JG568oBQFS/mvYg6OOncjDrsHLSeo1Crwhas mQm0UbutbmcPiXee/D/xXbTgEczzy6+ROv0Dhx1ARXNxLyolzL6MWrVDBNQqrZo/ CkFaeT1ZKwVkLmYUyVuxrVKgYjCJL/sqyTDQGFhI+15LLTfKe1bR1XaaeQBMBX/+ VPwIrRNj74GjMfaRS+JOfKif2pNzTSeBkY+A7Cg0Ru08HdsoPqCKB1LpUU6N9oLT YRF4oCK3P955fB78QuaonqwPiWpm5LA76rhFXLHS5KgGBrSMjSvmLGnX3ujttosn 5qsjb75JRn/phc5PApXH =/cPv -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Feb_17_09:48:33_2015-1-- From owner-freebsd-fs@FreeBSD.ORG Mon Feb 16 22:41:03 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CDA810B; Mon, 16 Feb 2015 22:41:03 +0000 (UTC) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (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 E357BD49; Mon, 16 Feb 2015 22:41:02 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id nt9so47049733obb.3; Mon, 16 Feb 2015 14:41:02 -0800 (PST) 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=jNNg4ARYPqrtelK9X1lWV5TGpwMezAEN9PkKHfKFv7o=; b=ZP4h/Nw+fJgw7ybk2op4nhuA4guyefEYyRiqTqcminI/vDTpCn8CgomP4Bled34sKU kceQXB1Ct5z7DAfi3aPSHmdsrmAaXG4pGbKXFTTvmfBk07joRB39V7gCXYCCnF73pim2 hK7Wfg0wa1KnedeSBkI11saRQTO9Yjlje2KkwPI8AZSpnLZYOPHMCECdjdT8dqLPOYMe kF0xsRLPEpNBP/Pj3yODMHd181BtgHc7/pxg/tWmW+FE9+FHe7qje4G/DtvqYnBMtx7+ 74sJjdysBZzrRIh7fYjjuzfkiC10Y8VvVj0EqjoS7VFpFDSS0UoHpfjTvYCRfY+RDKQR Mw1w== MIME-Version: 1.0 X-Received: by 10.182.43.129 with SMTP id w1mr16886932obl.86.1424126462250; Mon, 16 Feb 2015 14:41:02 -0800 (PST) Received: by 10.76.68.10 with HTTP; Mon, 16 Feb 2015 14:41:02 -0800 (PST) Date: Mon, 16 Feb 2015 17:41:02 -0500 Message-ID: Subject: zfs set running_with_scissors=on zroot From: Zaphod Beeblebrox To: FreeBSD Hackers , freebsd-fs Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 22:41:03 -0000 I've been struggling for awhile with zdb and friends recovering some data from a curiously problematic old ZFS array and I had an idea: Why not add a 'running_with_scissors' or maybe more properly named 'read_what_you_got_anyways' flag to zfs. Maybe this produces some garbage for a problem file or maybe it doesn't I see two scenarios where this is useful: 1) where ZFS has declared an "error" somewhere where a scrub will eventually remove that error. 2) where ZFS is having some sort of problem and the user just wants to try pushing through it. My concept of "how this would work" is that the flag would stop the machinery that would normally stop the data from being delivered. Note that case (1) might also be ameliorated by a flag or behavior that rechecked only the blocks and checksums of data in question. Right now, if ZFS has "declared" something bad, it will return an error when you access it --- even if a subsequent "scrub" would remove that flag --- that scrub can take many, many hours. From owner-freebsd-fs@FreeBSD.ORG Tue Feb 17 10:24:28 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55B49B4B for ; Tue, 17 Feb 2015 10:24:28 +0000 (UTC) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) (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 12FF8CE8 for ; Tue, 17 Feb 2015 10:24:26 +0000 (UTC) Received: from [78.35.133.36] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YNfKE-0000Xf-MQ for freebsd-fs@freebsd.org; Tue, 17 Feb 2015 11:24:18 +0100 Date: Tue, 17 Feb 2015 11:24:27 +0100 From: Fabian Keil To: freebsd-fs@freebsd.org Subject: Re: zfs set running_with_scissors=on zroot Message-ID: <20895a7f.19949a2f@fabiankeil.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/1Iw+zkUI/1cgO5TnoNeb8Sn"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 10:24:28 -0000 --Sig_/1Iw+zkUI/1cgO5TnoNeb8Sn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Zaphod Beeblebrox wrote: > I've been struggling for awhile with zdb and friends recovering some data > from a curiously problematic old ZFS array and I had an idea: >=20 > Why not add a 'running_with_scissors' or maybe more properly named > 'read_what_you_got_anyways' flag to zfs. >=20 > Maybe this produces some garbage for a problem file or maybe it doesn't I > see two scenarios where this is useful: >=20 > 1) where ZFS has declared an "error" somewhere where a scrub will > eventually remove that error. >=20 > 2) where ZFS is having some sort of problem and the user just wants to try > pushing through it. >=20 > My concept of "how this would work" is that the flag would stop the > machinery that would normally stop the data from being delivered. I missed such a feature in the past as well, however I don't remember having seen this behaviour so far: > Note that case (1) might also be ameliorated by a flag or behavior that > rechecked only the blocks and checksums of data in question. Right now, = if > ZFS has "declared" something bad, it will return an error when you access > it --- even if a subsequent "scrub" would remove that flag --- that scrub > can take many, many hours. I'm using several pools where temporary read errors (USB disconnects etc.) resulted in "zpool status -v" showing files with "Permanent errors", however the files can be still read completely and the returned data is valid. While I sometimes see files with errors that can't be completely read anymore, I've seen no indication so far that the files actually aren't corrupted on disk. Usually this happens when writing to a pool whose vdevs get temporarily disconnected and reconnected without exporting the pool first. Fabian --Sig_/1Iw+zkUI/1cgO5TnoNeb8Sn Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlTjFtgACgkQBYqIVf93VJ3oMwCglCBIkHRkLtKuVLCRCnXP7DTJ gMAAnAjlw05fvxxwuUVqsc9b5TlDI2kD =jOSP -----END PGP SIGNATURE----- --Sig_/1Iw+zkUI/1cgO5TnoNeb8Sn-- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 18 04:01:23 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36DDD6C1 for ; Wed, 18 Feb 2015 04:01:23 +0000 (UTC) Received: from server949-han.de-nserver.de (server949-han.de-nserver.de [77.75.250.185]) (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 991643E8 for ; Wed, 18 Feb 2015 04:01:21 +0000 (UTC) Received: (qmail 25622 invoked from network); 18 Feb 2015 05:01:12 +0100 X-Fcrdns: Yes Received: from dslb-094-218-010-244.094.218.pools.vodafone-ip.de (HELO midgard.local) (94.218.10.244) (smtp-auth username konstantin@schukraft.org, mechanism plain) by server949-han.de-nserver.de (qpsmtpd/0.92) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA; Wed, 18 Feb 2015 05:01:12 +0100 Message-ID: <54E40E86.1030805@schukraft.org> Date: Wed, 18 Feb 2015 05:01:10 +0100 From: Konstantin Schukraft User-Agent: "" MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Fwd: current status RE: "File name too long" issues References: <54E1F020.8040107@schukraft.org> In-Reply-To: <54E1F020.8040107@schukraft.org> X-Forwarded-Message-Id: <54E1F020.8040107@schukraft.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-User-Auth: Auth by konstantin@schukraft.org through 94.218.10.244 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 04:01:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I just realised I only sent this email to freebsd-questions@, I intended to send a copy to freebsd-fs@ as well, given the nature of the problem. So here you go, any input into this problem is appreciated. All the best, Konstantin - -------- Forwarded Message -------- From: - Mon Feb 16 14:26:58 2015 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00800000 X-Mozilla-Keys: Message-ID: <54E1F020.8040107@schukraft.org> Date: Mon, 16 Feb 2015 14:26:56 +0100 From: Konstantin Schukraft User-Agent: "" MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: current status RE: "File name too long" issues Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, this seems a rather old issue that's still alive, manifesting in NFS mounts, nullfs mounts with jails, etc: "Overly" long path names in these situations result in an error like "mount_nullfs: : File name too long". I, for example, run into this every time I try to setup a poudriere jail, others seem too. Since the forums didn't really provide an answer, I'll ask here: Is there work currently being done on this issue? Because this reply: https://docs.freebsd.org/cgi/getmsg.cgi?fetch=210593+0+/usr/local/www/db/text/2014/freebsd-questions/20141221.freebsd-questions seems to indicate this has been fixed, which definitely isn't the case for many people, including myself. So what's the status on that? Am I overlooking something important? Thank you, Konstantin -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJU5A5+AAoJEH3raMNeVmMFTkIP/2JaBgHwY84bTSc4OYGRAuCB LxkGC3BdpGAxvE6BHJgrAPEPHDEhUUyuNwm/LiuvjqCqO+2e8yMEJ6vR69XBdKX1 t2aXIlF/si/WUgDOHp9veuSb9a8aMz+C0aTXIb+OFwPDKfQu22NARp2edRVM1znT 17unGUuM1qxxeW1jyEQbGqAxysDCNjCGPp6cVeJRL8b8eGjd8lNwe/6St9O6gDON Yjj6RZGU5BXBruZk2Fn71U9mt+sbfAXUvs0tQpV805oW/ymQcxXVfkjBkqeh5ZlV RthXswsqRmf4tUJX7A0lHRGL+8OFUxpTJGb+yrrDicH85NgpZGEh5BJGYeFE1jOk uDnNmYx4EC2Qe9bHDqzCT3JtfjscsR2yzhP3TXaHicPOZsr9SjXQOE+OKp3luGUa v9EsAXepRPFqgwn3qqEqBVgTXjeVWNOtFEFV0aEBmsEfco3q/ZpIV/hS3UpyK+Ed 0L8SqrkRSyDJ6s6MTYpoHp/Q8AUT9wkoShJxKoAb/psSvHsmGRvbu0pweA9AMBw8 7bXkLY10WlCkkH8Vn9u4oUlvlKjGfBUMlTzW4laLE+1lAbW6gedNd7eerhI+Z3rS NnVWuDBFWJyB08V+gDcJ4i/PfqCGJIJWqE6EQEr2pYSf5H542GZ7WgAJoENpi/C0 m00aK6ZHvY28sAtR1zeh =/tUC -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 18 07:30:47 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22F2A1A3 for ; Wed, 18 Feb 2015 07:30:47 +0000 (UTC) Received: from nm15-vm1.access.bullet.mail.gq1.yahoo.com (nm15-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.13]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD944BEA for ; Wed, 18 Feb 2015 07:30:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1424244533; bh=iVToN6kE4eS4ECum1o+p49AHEvMry3PGOe5bW6hufJE=; h=From:Date:To:Cc:Subject:In-Reply-To:References:From:Subject; b=OqBqPUcQCRRMtCHW4d6cxk0VkaiJQ1sWXVteY83V7xtFrdQSFJmFUqwBvsuHhZRiSv7iW1y/kuNODHm7yc/cyR9guqnKvY/GC5G/9NsdOeYlXh9greImnzld2I3/TRQ8MV6qu2CNDIgs0CHpFa8xajuXfaZxGA3/+NVf7c6LQb6f9O+fKncEKsuAam9ae3hNkTwkWs8zk6FgmYQKx0Eo44+BUyCAgPILIrtzbx62BJWFRzMkKzdTAwv8ytSpZujZ7KmEAn4dL0szYqEv4NcGDe1rjDF5BNK8slZdmxDVFgyD9/1RdKUjFSS3iv5DeEpyT4HEtICALLZUZb9nTon8YQ== Received: from [216.39.60.167] by nm15.access.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2015 07:28:53 -0000 Received: from [98.138.226.243] by tm3.access.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2015 07:28:53 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 18 Feb 2015 07:28:53 -0000 X-Yahoo-Newman-Id: 109487.20878.bm@smtp114.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: uAiP04QVM1mgOcK2LIj5jN5LbgutZAERa59q4XokLcgL1Bp bC7.5fGcpTMN7YFG_st1DZO61YNXo9ry1b.uuuGylE_syc_cH0QWyG4HFh6T nm4woowHQcntL5D_UgkBbaRxRU2xm47RS9EMZWAyGzDkRWteVnRm1448l3rC 0ABmWGNROsLNK7Oux7yo5Q3mQ2FJ9ICD.N4T20pgujzBhqY9Q__ROIRke8PU 6OypYA3WY7lM.vHOk_QJi4vJthIzeu3qalk1xnl8nKj8NFedWPk1R1tl6dB7 orhmCzILjh6WquuMy4BhDWrEqxR4gKQJPFVOtrJjM7GXlexTnayD9Z.Y3aWm D1mTs3ZoTwkIcK29ePZ7JNnfKTv53vGuTkGxzqcgQajiP3fLw5FzWiiLnIEf Ds7deXsyO1plISezveWlv9F4r5F8E5ZDzd5KLDuuHsA2upLbYz2N2JwjASmr NkPiERZOdhjoSncG9v0pYv80B5BmjmBuGEy_0G9uWZUUuMW5EH7jLinlTCVo QIgAxt.57zsh8TVlz17eej3tnFAxBTparxQ-- X-Yahoo-SMTP: knGM_HSswBD5QyvFslEk1_6tqt5exkIU26bBrTLyCA-- Received: by osprey.kermodei.com (Postfix, from userid 1000) id B33CC3C0D; Tue, 17 Feb 2015 23:28:51 -0800 (PST) From: Mark Diekhans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21732.16179.684304.898642@osprey.kermodei.com> Date: Tue, 17 Feb 2015 23:28:51 -0800 To: Konstantin Schukraft Subject: Fwd: current status RE: "File name too long" issues In-Reply-To: <54E40E86.1030805@schukraft.org> References: <54E1F020.8040107@schukraft.org> <54E40E86.1030805@schukraft.org> X-Mailer: VM 8.2.0b under 24.4.1 (amd64-portbld-freebsd9.1) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 07:30:47 -0000 This issue also exists for ZFS snapshots. One can generate snapshot names that FreeBSD then can't mount. Very frustrating to have to work around this. Konstantin Schukraft writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > I just realised I only sent this email to freebsd-questions@, I > intended to send a copy to freebsd-fs@ as well, given the nature of > the problem. So here you go, any input into this problem is appreciated. > > > All the best, > > Konstantin From owner-freebsd-fs@FreeBSD.ORG Wed Feb 18 15:10:57 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13DF8B62 for ; Wed, 18 Feb 2015 15:10:57 +0000 (UTC) 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 EDDCA382 for ; Wed, 18 Feb 2015 15:10:56 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t1IFAuXg021144 for ; Wed, 18 Feb 2015 15:10:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 132960] [ufs] [panic] panic:ffs_blkfree: freeing free frag Date: Wed, 18 Feb 2015 15:10:56 +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: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: michelle@sorbs.net 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: 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 15:10:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=132960 Michelle Sullivan changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michelle@sorbs.net --- Comment #4 from Michelle Sullivan --- On 9.3-i386 as well... http://flashback.sorbs.net/packages/crash/9.3-i386/core.txt.0.1424267734 Unread portion of the kernel message buffer: dev = ada0p2, block = 807357, fs = / panic: ffs_blkfree_cg: freeing free frag cpuid = 1 KDB: stack backtrace: #0 0xc0b0f96f at kdb_backtrace+0x4f #1 0xc0ad65af at panic+0x16f #2 0xc0d08172 at ffs_blkfree_cg+0x502 #3 0xc0d083ee at ffs_blkfree+0x9e #4 0xc0d2055b at freework_freeblock+0x51b #5 0xc0d22cf9 at handle_workitem_freeblocks+0x329 #6 0xc0d2166a at process_worklist_item+0x26a #7 0xc0d26241 at softdep_process_worklist+0x91 #8 0xc0d29070 at softdep_flush+0x3e0 #9 0xc0aa243f at fork_exit+0xcf #10 0xc0f88764 at fork_trampoline+0x8 Uptime: 17m3s Physical memory: 3499 MB Dumping 418 MB: 403 387 371 355 339 323 307 291 275 259 243 227 211 195 179 163 147 131 115 99 83 67 51 35 19 3 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko #0 doadump (textdump=1) at pcpu.h:250 250 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:250 #1 0xc0ad62f5 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:454 #2 0xc0ad65f2 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:642 #3 0xc0d08172 in ffs_blkfree_cg (ump=0xc8493300, fs=0xc84a0000, devvp=0xc848d000, bno=807357, size=12288, inum=401407, dephd=0xee76eba4) at /usr/src/sys/ufs/ffs/ffs_alloc.c:2186 #4 0xc0d083ee in ffs_blkfree (ump=0xc8493300, fs=0xc84a0000, devvp=0xc848d000, bno=807357, size=12288, inum=401407, vtype=VREG, dephd=0xee76eba4) at /usr/src/sys/ufs/ffs/ffs_alloc.c:2292 #5 0xc0d2055b in freework_freeblock (freework=0xca18b500) at /usr/src/sys/ufs/ffs/ffs_softdep.c:7563 #6 0xc0d22cf9 in handle_workitem_freeblocks (freeblks=0xca0ce500, flags=512) at /usr/src/sys/ufs/ffs/ffs_softdep.c:7717 #7 0xc0d2166a in process_worklist_item (mp=0xc848bd34, target=10, flags=512) at /usr/src/sys/ufs/ffs/ffs_softdep.c:1807 #8 0xc0d26241 in softdep_process_worklist (mp=0xc848bd34, full=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:1591 #9 0xc0d29070 in softdep_flush () at /usr/src/sys/ufs/ffs/ffs_softdep.c:1447 #10 0xc0aa243f in fork_exit (callout=0xc0d28c90 , arg=0x0, frame=0xee76ed08) at /usr/src/sys/kern/kern_fork.c:996 #11 0xc0f88764 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:279 (kgdb) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 18 19:23:01 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BA212C9 for ; Wed, 18 Feb 2015 19:23:01 +0000 (UTC) Received: from smtp.atelo.org (atelo.org [198.100.144.64]) by mx1.freebsd.org (Postfix) with ESMTP id 745DBA62 for ; Wed, 18 Feb 2015 19:23:01 +0000 (UTC) Received: from coyotlan (cpe-76-88-16-9.san.res.rr.com [76.88.16.9]) by smtp.atelo.org (Postfix) with ESMTPSA id 50E6474A854 for ; Wed, 18 Feb 2015 11:14:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=atelo.org; s=mail; t=1424286879; bh=JBv8NVxAb0PrC6x/YWC41l/etdwZhl2RYQ94ji+1f0s=; h=Date:From:To:Subject; b=fc1j2FZL5TmUlbSGXKstbAxzKE1GqmXzzjCgb5VCwB0ycpESKOyIJtg9bHNQfNyBX ymbpmdIEOJrJC9OdvqOfoxZTArrXoWOrM45nOK4xbqhg/hEG4TrjwatJxQJbwvLDXJ SEirkTF8K2Qzba7f15kyscuk4U6mbavkyBel3Zsc= Received: from localhost (coyotlan [local]); by coyotlan (OpenSMTPD) with ESMTPA id d63e85e1; for ; Wed, 18 Feb 2015 19:13:45 +0000 (UTC) Date: Wed, 18 Feb 2015 11:13:45 -0800 From: =?utf-8?B?WMSrY8Oy?= To: freebsd-fs@freebsd.org Subject: ZFS root set to readonly=on temporary at boot Message-ID: <20150218191345.GA31812@coyotlan.Tlalpan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 19:23:01 -0000 Dear freebsd-fs, As I am trying to install a new small server with a most partitions on ZFS, I am running into some little read-only troubles. At boot the root is always set to read-only. The rest of the system is fine though: # zfs get all | grep readonly zroot readonly on temporary zroot/tmp readonly off inherited from zroot zroot/usr readonly off inherited from zroot […] I cannot seem to understand what may cause this issue. The system is a typical manual [1] installation (used to work fine), on an empty system. Note that I can reset the root to readonly=off with: # zfs set readonly=off zroot but it is a pain to to it manually without understanding why. I also cannot seem to get much info from the log messages: ==> /var/log/messages <== Feb 18 18:56:24 kernel: Root mount waiting for: usbus4 Feb 18 18:56:24 last message repeated 2 times Feb 18 18:56:24 kernel: uhub4: 8 ports with 8 removable, self powered Feb 18 18:56:24 kernel: Root mount waiting for: usbus4 Feb 18 18:56:24 kernel: ugen4.2: at usbus4 Feb 18 18:56:24 kernel: uhub5: on usbus4 Feb 18 18:56:24 kernel: uhub5: 4 ports with 4 removable, self powered Feb 18 18:56:24 kernel: Trying to mount root from zfs:zroot [rw]... Feb 18 18:56:29 kernel: . Feb 18 18:56:30 kernel: . There are a couple of mentions to this same problem in 2012 on this mailing list [2] and on an unanswered forum message [3], but they did not solve the issue (setting vfs.root.mountfrom.options=rw only changes the log message). The machine starts its other services (such as SSH) correctly though. Hope someone will have an idea. Best, Xīcò [1] https://blog.gegeweb.org/article30/freebsd-9-2-en-full-zfs-sur-un-kimsufi-ps-4g [2] https://lists.freebsd.org/pipermail/freebsd-fs/2012-February/013654.html [3] https://forums.freebsd.org/threads/zfs-readonly-on-temporary-on-boot.28944/ From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 02:10:52 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A651199 for ; Thu, 19 Feb 2015 02:10:52 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 27FA582A for ; Thu, 19 Feb 2015 02:10:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AXBQBxReVU/95baINbg1haBIMEv1YOhSNKAoFiAQEBAQEBfIQMAQEBAwEBAQEgKyALGxEDAQIBAgINGQIpAQkVCQgGCAIFBAEcBIgGCA26DJhHAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiW6CYYErCwUCARs0BwaCYoFCBYpDiFuDRoM4OIJYjm4iggEdgW4gMQEBBXxBfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,605,1418101200"; d="scan'208";a="191708739" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 18 Feb 2015 21:09:48 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4BCABB3F28; Wed, 18 Feb 2015 21:09:48 -0500 (EST) Date: Wed, 18 Feb 2015 21:09:48 -0500 (EST) From: Rick Macklem To: Konstantin Schukraft Message-ID: <1545385378.6062525.1424311788292.JavaMail.root@uoguelph.ca> In-Reply-To: <54E40E86.1030805@schukraft.org> Subject: Re: current status RE: "File name too long" issues MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 02:10:52 -0000 Konstantin Schukraft wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > I just realised I only sent this email to freebsd-questions@, I > intended to send a copy to freebsd-fs@ as well, given the nature of > the problem. So here you go, any input into this problem is > appreciated. > > > All the best, > > Konstantin > > > - -------- Forwarded Message -------- > From: - Mon Feb 16 14:26:58 2015 > X-Mozilla-Status: 0001 > X-Mozilla-Status2: 00800000 > X-Mozilla-Keys: > Message-ID: <54E1F020.8040107@schukraft.org> > Date: Mon, 16 Feb 2015 14:26:56 +0100 > From: Konstantin Schukraft > User-Agent: "" > MIME-Version: 1.0 > To: freebsd-questions@freebsd.org > Subject: current status RE: "File name too long" issues > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: 8bit > > Hi, > > this seems a rather old issue that's still alive, manifesting in NFS > mounts, nullfs mounts with jails, etc: > "Overly" long path names in these situations result in an error like > "mount_nullfs: : File name too long". I, for example, run into > this every time I try to setup a poudriere jail, others seem too. > > Since the forums didn't really provide an answer, I'll ask here: > Is there work currently being done on this issue? Because this reply: > https://docs.freebsd.org/cgi/getmsg.cgi?fetch=210593+0+/usr/local/www/db/text/2014/freebsd-questions/20141221.freebsd-questions > seems to indicate this has been fixed, which definitely isn't the > case > for many people, including myself. > > So what's the status on that? Am I overlooking something important? > As far as I know, the 88 byte limit for paths still applies. You can easily change the value of MNAMELEN in sys/sys/mount.h and rebuild everything from these modified sources. However, FreeBSD cannot do this, since it breaks the statfs(2) syscall interface and users of it. In svn's projects/ino64, there is work in progress on this + changing ino_t to be 64bits. Hopefully this work will make in it FreeBSD11. If there is a new system call that replaces the current statfs(2) that ends up with a different name, it might be possible to MFC this and have statfs(2) return a truncated path. I believe there is a patch floating around that allows NFS mounts with longer paths to work, truncating the path for statfs(2), but this is not in -current etc. If others know more or if I've gotten this incorrect, please correct me, rick > > Thank you, > > Konstantin > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCAAGBQJU5A5+AAoJEH3raMNeVmMFTkIP/2JaBgHwY84bTSc4OYGRAuCB > LxkGC3BdpGAxvE6BHJgrAPEPHDEhUUyuNwm/LiuvjqCqO+2e8yMEJ6vR69XBdKX1 > t2aXIlF/si/WUgDOHp9veuSb9a8aMz+C0aTXIb+OFwPDKfQu22NARp2edRVM1znT > 17unGUuM1qxxeW1jyEQbGqAxysDCNjCGPp6cVeJRL8b8eGjd8lNwe/6St9O6gDON > Yjj6RZGU5BXBruZk2Fn71U9mt+sbfAXUvs0tQpV805oW/ymQcxXVfkjBkqeh5ZlV > RthXswsqRmf4tUJX7A0lHRGL+8OFUxpTJGb+yrrDicH85NgpZGEh5BJGYeFE1jOk > uDnNmYx4EC2Qe9bHDqzCT3JtfjscsR2yzhP3TXaHicPOZsr9SjXQOE+OKp3luGUa > v9EsAXepRPFqgwn3qqEqBVgTXjeVWNOtFEFV0aEBmsEfco3q/ZpIV/hS3UpyK+Ed > 0L8SqrkRSyDJ6s6MTYpoHp/Q8AUT9wkoShJxKoAb/psSvHsmGRvbu0pweA9AMBw8 > 7bXkLY10WlCkkH8Vn9u4oUlvlKjGfBUMlTzW4laLE+1lAbW6gedNd7eerhI+Z3rS > NnVWuDBFWJyB08V+gDcJ4i/PfqCGJIJWqE6EQEr2pYSf5H542GZ7WgAJoENpi/C0 > m00aK6ZHvY28sAtR1zeh > =/tUC > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 10:28:18 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2070385F for ; Thu, 19 Feb 2015 10:28:18 +0000 (UTC) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id D71E7EC2 for ; Thu, 19 Feb 2015 10:28:17 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 0FFBF421582; Thu, 19 Feb 2015 21:27:58 +1100 (AEDT) Date: Thu, 19 Feb 2015 21:27:50 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rick Macklem Subject: Re: current status RE: "File name too long" issues In-Reply-To: <1545385378.6062525.1424311788292.JavaMail.root@uoguelph.ca> Message-ID: <20150219203111.W4301@besplex.bde.org> References: <1545385378.6062525.1424311788292.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=Za4kaKlA c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=6I5d2MoRAAAA:8 a=9ki36j1ue2UxshM84WIA:9 a=CjuIK1q_8ugA:10 Cc: freebsd-fs@freebsd.org, Konstantin Schukraft X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 10:28:18 -0000 On Wed, 18 Feb 2015, Rick Macklem wrote: > Konstantin Schukraft wrote: >> I just realised I only sent this email to freebsd-questions@, I >> ... >> - -------- Forwarded Message -------- >> ... >> this seems a rather old issue that's still alive, manifesting in NFS >> mounts, nullfs mounts with jails, etc: >> "Overly" long path names in these situations result in an error like >> "mount_nullfs: : File name too long". I, for example, run into >> this every time I try to setup a poudriere jail, others seem too. >> >> Since the forums didn't really provide an answer, I'll ask here: >> Is there work currently being done on this issue? Because this reply: >> https://docs.freebsd.org/cgi/getmsg.cgi?fetch=210593+0+/usr/local/www/db/text/2014/freebsd-questions/20141221.freebsd-questions >> seems to indicate this has been fixed, which definitely isn't the >> case >> for many people, including myself. >> >> So what's the status on that? Am I overlooking something important? >> > As far as I know, the 88 byte limit for paths still applies. > You can easily change the value of MNAMELEN in sys/sys/mount.h and > rebuild everything from these modified sources. mount() used to work. The saved pathname in the statfs struct is only informational, but mount() has been broken to make this the limit on the syscall. This doesn't even work to give a uniform limit, since some file systems save the path in the superblock and have more or less space than MNAMELEN for this, depending on the file system. > However, FreeBSD cannot do this, since it breaks the statfs(2) syscall > interface and users of it. Unbreaking mount() doesn't break the ABI. Of course, everything using struct statfs can only display a truncated name, and there is no alternative to using struct statfs since the name is not saved anywhere else. Except sometimes in superblocks, but there is no user API to fetch the name from there. > In svn's projects/ino64, there is work in progress on this + changing > ino_t to be 64bits. Hopefully this work will make in it FreeBSD11. > If there is a new system call that replaces the current statfs(2) that > ends up with a different name, it might be possible to MFC this and > have statfs(2) return a truncated path. > > I believe there is a patch floating around that allows NFS mounts > with longer paths to work, truncating the path for statfs(2), but > this is not in -current etc. BSD-old through FreeBSD-4 does this without any patch. Bruce From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 10:30:05 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC6529D5 for ; Thu, 19 Feb 2015 10:30:05 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::9]) (using TLSv1.2 with cipher DHE-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 57B68EE0 for ; Thu, 19 Feb 2015 10:30:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1424341779; l=684; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From: Date; bh=CzdyJPmfo8lej6mLGr+NNIHbLZnQQRjGxrU1js+E43I=; b=BAj0qiA2GIvS8BeOHH7XJ8LEmxVV24tZBB5G3oAdS77DSNj7iuGbCOvokQMXBul8wml +1m0cqF8jFjAnws3l4DW/cptVUt4h0+pIZKY23t/VBQHt8p6223VlNa3It+3nlhT3NYlp 8wRaLTROzfcaPhFFL7owyDbav2QqzfnsOdw= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTL/JIGbzkGUoozgkO4q1xDEhkgOJDsXNs= X-RZG-CLASS-ID: mo00 Received: from fuckner.delnet ([85.183.0.195]) by smtp.strato.de (RZmta 37.3 AUTH) with ESMTPA id x07667r1JATdAR1 for ; Thu, 19 Feb 2015 11:29:39 +0100 (CET) Message-ID: <54E5BB12.3060707@fuckner.net> Date: Thu, 19 Feb 2015 11:29:38 +0100 From: Michael Fuckner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Creating zpool on NVMe Disks takes forever Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 10:30:05 -0000 Hi, I have two NVMe PCIe Cards in a System running 10.1-p5. root@s4l:~ # ll /dev/nv* crw-r----- 1 root operator 0x63 Feb 19 08:51 /dev/nvd0 crw-r----- 1 root operator 0x67 Feb 19 08:51 /dev/nvd1 crw------- 1 root wheel 0x30 Feb 19 08:51 /dev/nvme0 crw------- 1 root wheel 0x5c Feb 19 08:51 /dev/nvme0ns1 crw------- 1 root wheel 0x31 Feb 19 08:51 /dev/nvme1 crw------- 1 root wheel 0x62 Feb 19 08:51 /dev/nvme1ns1 I can partition/format the disks with UFS and access them without issues, but I can't create a zpool. It simply takes forever when I enter the following command: zpool create tank0 mirror nvd0 nvd1 Any idea what to check? Regards, Michael! From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 11:24:54 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D025536 for ; Thu, 19 Feb 2015 11:24:54 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D21FB6AA for ; Thu, 19 Feb 2015 11:24:53 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YOOxh-0005K0-Oz for freebsd-fs@freebsd.org; Thu, 19 Feb 2015 12:08:11 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: Creating zpool on NVMe Disks takes forever References: <54E5BB12.3060707@fuckner.net> Date: Thu, 19 Feb 2015 12:08:00 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <54E5BB12.3060707@fuckner.net> User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_40 autolearn=disabled version=3.3.2 X-Scan-Signature: 258bd43c1b7c380ff6f1b27dffaa1ebc X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 11:24:54 -0000 On Thu, 19 Feb 2015 11:29:38 +0100, Michael Fuckner wrote: > Hi, > > I have two NVMe PCIe Cards in a System running 10.1-p5. > > root@s4l:~ # ll /dev/nv* > crw-r----- 1 root operator 0x63 Feb 19 08:51 /dev/nvd0 > crw-r----- 1 root operator 0x67 Feb 19 08:51 /dev/nvd1 > crw------- 1 root wheel 0x30 Feb 19 08:51 /dev/nvme0 > crw------- 1 root wheel 0x5c Feb 19 08:51 /dev/nvme0ns1 > crw------- 1 root wheel 0x31 Feb 19 08:51 /dev/nvme1 > crw------- 1 root wheel 0x62 Feb 19 08:51 /dev/nvme1ns1 > > I can partition/format the disks with UFS and access them without > issues, but I can't create a zpool. It simply takes forever when I enter > the following command: > > zpool create tank0 mirror nvd0 nvd1 > > > Any idea what to check? > > Regards, > Michael! I don't have NVMe and don't know if you use HDDs or SSDs or something else even. So, just a guess: sysctl vfs.zfs.vdev.trim_on_init Regards, Ronald. From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 11:56:41 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F02D6F53 for ; Thu, 19 Feb 2015 11:56:41 +0000 (UTC) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (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 856CAA1A for ; Thu, 19 Feb 2015 11:56:41 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id l18so6745033wgh.8 for ; Thu, 19 Feb 2015 03:56:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WoH/GzzmARHEaiiD7uu/3lrcnou/Cep3t/RHbeHqDGg=; b=TSUcAkikVrpmdDbmYPzYLbr/GwgZb6FGusZ+ibuve/mU/tyKZwWX7DYJsr0Q4SAHX0 0ff4368btRlQfE78ma10ohbjOL7IStjYnwhtMRlSR+hInwrJpRRVIkHcf1Cy/oZjpj2D /Z4AKKqSOlvUVuA5JW41MlR9hD0IUc6wRfMksCLAtq75DNn0JShh8bz3M6R6TYXVwjQI jj5mTzsiE5qo3eVRTKSUWzVmnybQrt7CZ3ozm55Z71wr1srd9TNZQQS3k0/1HgH24Nfl 7YCIOl1eaoOc6+njfATprRvCu57Z0jvvdCyx655+DEmm8VeycJvTLrCGfjhlhB4R2MkB ANNA== X-Gm-Message-State: ALoCoQkdm7ujCHX9bZxU1q4zpa94hm0s/LTUo/jtqUE/RDPiR+rWlerm6nfRkwbIAvuYsK71FHBw X-Received: by 10.180.89.173 with SMTP id bp13mr5610499wib.88.1424346994092; Thu, 19 Feb 2015 03:56:34 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id hg7sm37070392wjb.44.2015.02.19.03.56.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Feb 2015 03:56:32 -0800 (PST) Message-ID: <54E5CF6E.5030906@multiplay.co.uk> Date: Thu, 19 Feb 2015 11:56:30 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Creating zpool on NVMe Disks takes forever References: <54E5BB12.3060707@fuckner.net> In-Reply-To: <54E5BB12.3060707@fuckner.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 11:56:42 -0000 Disable trim on init: sysctl vfs.zfs.vdev.trim_on_init=0 On 19/02/2015 10:29, Michael Fuckner wrote: > Hi, > > I have two NVMe PCIe Cards in a System running 10.1-p5. > > root@s4l:~ # ll /dev/nv* > crw-r----- 1 root operator 0x63 Feb 19 08:51 /dev/nvd0 > crw-r----- 1 root operator 0x67 Feb 19 08:51 /dev/nvd1 > crw------- 1 root wheel 0x30 Feb 19 08:51 /dev/nvme0 > crw------- 1 root wheel 0x5c Feb 19 08:51 /dev/nvme0ns1 > crw------- 1 root wheel 0x31 Feb 19 08:51 /dev/nvme1 > crw------- 1 root wheel 0x62 Feb 19 08:51 /dev/nvme1ns1 > > I can partition/format the disks with UFS and access them without > issues, but I can't create a zpool. It simply takes forever when I > enter the following command: > > zpool create tank0 mirror nvd0 nvd1 > > > Any idea what to check? > > Regards, > Michael! > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 12:20:41 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 831099E1 for ; Thu, 19 Feb 2015 12:20:41 +0000 (UTC) Received: from mail-yh0-f51.google.com (mail-yh0-f51.google.com [209.85.213.51]) (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 45375CBC for ; Thu, 19 Feb 2015 12:20:40 +0000 (UTC) Received: by yhab6 with SMTP id b6so4411028yha.10 for ; Thu, 19 Feb 2015 04:20:39 -0800 (PST) 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=MWdCOX2wY4z1+YQ9ffUzNOQGWofGS+43VRKvkFs9pQQ=; b=Aa1GLpMjApdfB/X4d3Wjdap39RQjZBMwEF1dY0GqiKBZZzZFHZzlp5LDZkQmiDf9+G /wK8ICp/w4H1MetPR8CZnjIHZBv7m/IHMDXF2cCsV0GEc1OXM7580a3tIsg3W7CH4O7b XFFXIwFmklgx5FKgwhCFa1JY5AFvZER+BcL3p4jQC/Q9hU/Tq7U+Aimr7/NlUlZoqTWO JyGpS9GkVWl/lb3Rr317WkOzBGcM//S3r4dbfii9gBH2TnWgvcDeuIut4IL05IY+5l1f a3jKJTaLwkNMzJd5a/en8BHdHcHQoSfNvtHl/xcESKDKPfpKiLRV7LwGEuC/hdJiIcaG B5Ng== MIME-Version: 1.0 X-Received: by 10.236.41.105 with SMTP id g69mr2401720yhb.55.1424347974834; Thu, 19 Feb 2015 04:12:54 -0800 (PST) Received: by 10.170.188.1 with HTTP; Thu, 19 Feb 2015 04:12:54 -0800 (PST) In-Reply-To: <20150218191345.GA31812@coyotlan.Tlalpan> References: <20150218191345.GA31812@coyotlan.Tlalpan> Date: Thu, 19 Feb 2015 12:12:54 +0000 Message-ID: Subject: Re: ZFS root set to readonly=on temporary at boot From: krad To: =?UTF-8?B?WMSrY8Oy?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD FS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 12:20:41 -0000 Check your bootfs and the / file system actually match up. Its quite easy to get odd things happening if you have the bootfs set to a filesystem that then has an fstab which then tells / is on another fs. Also check the loader.conf on the bootfs. In my experiance its safer to have clean fstabs, and nothing in the loader.conf (in relation to this) and just relay on the bootfs pool property On 18 February 2015 at 19:13, X=C4=ABc=C3=B2 wrote: > Dear freebsd-fs, > > As I am trying to install a new small server with a most partitions on > ZFS, I am running into some little read-only troubles. At boot the root > is always set to read-only. The rest of the system is fine though: > > # zfs get all | grep readonly > zroot readonly on temporar= y > zroot/tmp readonly off inherite= d > from zroot > zroot/usr readonly off inherite= d > from zroot > [=E2=80=A6] > > I cannot seem to understand what may cause this issue. The system is a > typical manual [1] installation (used to work fine), on an empty system. > > Note that I can reset the root to readonly=3Doff with: > > # zfs set readonly=3Doff zroot > > but it is a pain to to it manually without understanding why. I also > cannot seem to get much info from the log messages: > > =3D=3D> /var/log/messages <=3D=3D > Feb 18 18:56:24 kernel: Root mount waiting for: usbus4 > Feb 18 18:56:24 last message repeated 2 times > Feb 18 18:56:24 kernel: uhub4: 8 ports with 8 removable, self powered > Feb 18 18:56:24 kernel: Root mount waiting for: usbus4 > Feb 18 18:56:24 kernel: ugen4.2: at usbus4 > Feb 18 18:56:24 kernel: uhub5: 9/0, rev 2.00/1.00, addr 2> on usbus4 > Feb 18 18:56:24 kernel: uhub5: 4 ports with 4 removable, self powered > Feb 18 18:56:24 kernel: Trying to mount root from zfs:zroot [rw]... > Feb 18 18:56:29 kernel: . > Feb 18 18:56:30 kernel: . > > There are a couple of mentions to this same problem in 2012 on this > mailing list [2] and on an unanswered forum message [3], but they did > not solve the issue (setting vfs.root.mountfrom.options=3Drw only changes > the log message). The machine starts its other services (such as SSH) > correctly though. > > Hope someone will have an idea. > > Best, > > X=C4=ABc=C3=B2 > > [1] > https://blog.gegeweb.org/article30/freebsd-9-2-en-full-zfs-sur-un-kimsufi= -ps-4g > [2] > https://lists.freebsd.org/pipermail/freebsd-fs/2012-February/013654.html > [3] > https://forums.freebsd.org/threads/zfs-readonly-on-temporary-on-boot.2894= 4/ > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 12:22:42 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03E7EB19 for ; Thu, 19 Feb 2015 12:22:42 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (using TLSv1.2 with cipher DHE-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 8CFDDD71 for ; Thu, 19 Feb 2015 12:22:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1424348533; l=239; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date; bh=nh7jFdcAghIMHN/1hK9gmTLJ5dZcC5k8NwQl8A/wWdA=; b=H+V3oHotXN1tjrsDZyXwSsFyArEDUvit/DnmLvqfHQ5QJhwinMygI4uYLnpPr6f5Dve /wTm7x1kGNLL2V9swEPtBdoh2g7e8x0MCKvePfVE3bEc2AclTokeAAvVLUNW9CO9CtMDU G3v45wvoyL2PsIaSbPr04DaJ41HGL/euLso= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTL/JIGbzkGUoozgkO4q1xDEhkgOJDsXNs= X-RZG-CLASS-ID: mo00 Received: from fuckner.delnet ([85.183.0.195]) by smtp.strato.de (RZmta 37.3 AUTH) with ESMTPA id c01d09r1JCMDCTR for ; Thu, 19 Feb 2015 13:22:13 +0100 (CET) Message-ID: <54E5D574.8020406@fuckner.net> Date: Thu, 19 Feb 2015 13:22:12 +0100 From: Michael Fuckner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Creating zpool on NVMe Disks takes forever References: <54E5BB12.3060707@fuckner.net> <54E5CF6E.5030906@multiplay.co.uk> In-Reply-To: <54E5CF6E.5030906@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 12:22:42 -0000 On 02/19/2015 12:56 PM, Steven Hartland wrote: > Disable trim on init: > sysctl vfs.zfs.vdev.trim_on_init=0 this fixed it, thx! but why does it take >8h to trim 2x 400GB? Or is trimming handled differently on NVMe than on HDD/SSD? From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 13:02:29 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13FC035D for ; Thu, 19 Feb 2015 13:02:29 +0000 (UTC) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (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 D82221BD for ; Thu, 19 Feb 2015 13:02:28 +0000 (UTC) Received: by iecar1 with SMTP id ar1so9162920iec.11 for ; Thu, 19 Feb 2015 05:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=17bHzHp/ai7q9tB1/FTBVrs2CqcuXU3QIXZJP3fyMKE=; b=sUJrd5gt4q5MelqEfcePuV3kdv8XEmgN1hfHPxRPi1fosSEBe+5tbfiMpn1tg/RzRW TPKYU5DVYYECdUdZxGZ79KrJF9A/CnmueSLTrDSvZZLxwSzjdQ8tW3FkQz61LAJBb6Er RQcc1S7FF13Yc62RgfNzdspi2TyRPVtrgNZclvS7vB1mk/H/RsAVISo+V7/KSXxIS1Wa Chnq0IscQVIiVvxHkJecPnWK56VF+khJp+uhKOWcd8Hg+mAe3CGuoiTwuIH8xYmIEPKo EdDWEStzc9S+Jwsn7eDKkljX8jjk1SIN+d37SBk6kHnmuWE57ZFma2sws9G3Rx/P40Na 6soA== MIME-Version: 1.0 X-Received: by 10.107.16.226 with SMTP id 95mr5914064ioq.32.1424350942316; Thu, 19 Feb 2015 05:02:22 -0800 (PST) Received: by 10.107.14.199 with HTTP; Thu, 19 Feb 2015 05:02:22 -0800 (PST) In-Reply-To: <54E5D574.8020406@fuckner.net> References: <54E5BB12.3060707@fuckner.net> <54E5CF6E.5030906@multiplay.co.uk> <54E5D574.8020406@fuckner.net> Date: Thu, 19 Feb 2015 13:02:22 +0000 Message-ID: Subject: Re: Creating zpool on NVMe Disks takes forever From: Tom Evans To: Michael Fuckner Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD FS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 13:02:29 -0000 On Thu, Feb 19, 2015 at 12:22 PM, Michael Fuckner wrote: > On 02/19/2015 12:56 PM, Steven Hartland wrote: >> >> Disable trim on init: >> sysctl vfs.zfs.vdev.trim_on_init=0 > > this fixed it, thx! > > but why does it take >8h to trim 2x 400GB? Or is trimming handled > differently on NVMe than on HDD/SSD? TRIM/UNMAP is simply an SATA/SCSI command that is sent to a device. What the device does when it gets that command is up to the controller and firmware on the device. Cheers Tom From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 13:13:10 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DCE95B7 for ; Thu, 19 Feb 2015 13:13:10 +0000 (UTC) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (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 A8B3E2D2 for ; Thu, 19 Feb 2015 13:13:09 +0000 (UTC) Received: by wevm14 with SMTP id m14so7156111wev.13 for ; Thu, 19 Feb 2015 05:13:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/OaB4aDdgpCLPKZ3vwmfHOzNKUG3sfWVu/mrqGNNSkw=; b=PD7OCNxWVeOzHNXBolWnCtaQd12BTksTHnw2WUvVwKbe3EbnbudCsG+ajHE3Ml8OSl Mb4VwwOPhEm4F6XEjY0qCq+Gg64FclGC6aMIKIvqdBZ4keXnP4TimwiRefpgBvGomFhH hKdAaLIcgI+QGUPI3qrn6WjeYBUEl+RGSPVG2XePgL3dkHVWF90I+EKmZa1etMLDa6wD aUcqjObX4bS2GjaxDmxDJNORiH2L49/ujbnZ+V0LyzNalXRUOpIofS5aqaQOJPN4Dg8W ZBVd4rfZDh+x4MkS7TnasBW8KpuSFJuwr/Nr+xNIsZaa7egByvgmr1QA3iqFKR92NNIP tXgw== X-Gm-Message-State: ALoCoQkvgRCk9Il96zl2xymwexsCBJiAUvq2m/ECtUsn0QpPbiw6pS+s0UzY4kPMAVMff55qzguy X-Received: by 10.194.108.162 with SMTP id hl2mr9242938wjb.134.1424351582337; Thu, 19 Feb 2015 05:13:02 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id dt7sm24079510wib.19.2015.02.19.05.12.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Feb 2015 05:13:00 -0800 (PST) Message-ID: <54E5E159.1020407@multiplay.co.uk> Date: Thu, 19 Feb 2015 13:12:57 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Creating zpool on NVMe Disks takes forever References: <54E5BB12.3060707@fuckner.net> <54E5CF6E.5030906@multiplay.co.uk> <54E5D574.8020406@fuckner.net> In-Reply-To: <54E5D574.8020406@fuckner.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 13:13:10 -0000 On 19/02/2015 12:22, Michael Fuckner wrote: > On 02/19/2015 12:56 PM, Steven Hartland wrote: >> Disable trim on init: >> sysctl vfs.zfs.vdev.trim_on_init=0 > this fixed it, thx! > > but why does it take >8h to trim 2x 400GB? Or is trimming handled > differently on NVMe than on HDD/SSD? Sounds like very bad / slow trim support in NVMe? You might want to see what gstat -d -p shows From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 13:33:30 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A265AEC for ; Thu, 19 Feb 2015 13:33:30 +0000 (UTC) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (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 A40146D9 for ; Thu, 19 Feb 2015 13:33:29 +0000 (UTC) Received: by wesx3 with SMTP id x3so7327703wes.6 for ; Thu, 19 Feb 2015 05:33:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=16xfbCWYxVJ2oCQBz6a8iTrE1WMBiDprSQR3iJ1zbVE=; b=m3f5DpOqBgypadMPlkHMtE3yltQpfyqwtEFWaB4HnIu2yrM9eE22EU1tDcW4hc+LM+ 5021nZd95QM/IYc4uqGRa6h2WmHojiN0eiv0Dr2C/a7+PTING22c69tbN3/fl9C+XMwd uUd1XwlGx6+not4NzsQuZ/XxyhbD12JfIcQOUXxC1dlxSQ+J4Zhb3ikvRsEG8tNqg56p wqDm5Q3578YKU27J7CJ/G01GcWLnFudzVLI5JyNIFRCtNlGyKv/oLJ8IPOk7Cbn3dNv0 wfIWlkX+FBvium2b57abYfMOk74kUVnLyx17vGIgK0M0WF4jn4tqi3BtSbd7P78isDqS RE8A== X-Gm-Message-State: ALoCoQltu1RDF2eoJ3CFkLDknoYMIlr9/1Bpv02l92smv7H5aVzFmufEySSgDMF3Un5YKegaNlRy X-Received: by 10.180.21.133 with SMTP id v5mr6631147wie.27.1424352807779; Thu, 19 Feb 2015 05:33:27 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id kr5sm32486778wjc.1.2015.02.19.05.33.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Feb 2015 05:33:26 -0800 (PST) Message-ID: <54E5E624.2070301@multiplay.co.uk> Date: Thu, 19 Feb 2015 13:33:24 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Creating zpool on NVMe Disks takes forever References: <54E5BB12.3060707@fuckner.net> <54E5CF6E.5030906@multiplay.co.uk> <54E5D574.8020406@fuckner.net> 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 13:33:30 -0000 On 19/02/2015 13:02, Tom Evans wrote: > On Thu, Feb 19, 2015 at 12:22 PM, Michael Fuckner wrote: >> On 02/19/2015 12:56 PM, Steven Hartland wrote: >>> Disable trim on init: >>> sysctl vfs.zfs.vdev.trim_on_init=0 >> this fixed it, thx! >> >> but why does it take >8h to trim 2x 400GB? Or is trimming handled >> differently on NVMe than on HDD/SSD? > TRIM/UNMAP is simply an SATA/SCSI command that is sent to a device. > What the device does when it gets that command is up to the controller > and firmware on the device. > Technically is not TRIM / UNMAP its BIO_DELETE which is translated by the relevant device driver to the format the device understands. For SCSI this can be TRIM, UNMAP, WS or ZERO, for ATA this can be CFA_ERASE or TRIM and for NVMe this is a Deallocate. One reason why it might be slow is I don't see NVMe configuring geom d_delmaxsize, which if the case will force the "TRIM" to be split into single sector deallocation requests. Regards Steve From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 14:05:24 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EA13126 for ; Thu, 19 Feb 2015 14:05:24 +0000 (UTC) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (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 01B71A2D for ; Thu, 19 Feb 2015 14:05:23 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id l18so7418380wgh.8 for ; Thu, 19 Feb 2015 06:05:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=NQ1ZnYUE8I7vNs7AGl50QdQhig3VceYC/i20QxQtSjk=; b=PEV6TxzlYIy9HyKsZSax064aC/MmpxKmM6VnefJiu1hCoEp9CHajEOh38p+pyVTqE3 Pm2ACEJKZPgy0l+ke5qANSPhIIgD8UQtEJ+3jrPVIc0OhDWMlA5tAtCwDuiLcQ0iNoGA XT49Qv86gYHebZAhQJoxpGwM/21Nm8MiWQFxIWxkc5xe93Iz/kN0bTwkQyg3rb87agMn lPCZTC6XxytPLxtdQQWy1Fd/wh8vl4oX+nXvn7XZfKCIgUKnCFhtmNx1QnwL7YGAsqJs B1cZsAcq0B6hwTPAA/PUfUxMDN4JQOmmF1k+bDd7O+2wFQnzRmpDdODpqZCtMhG1id4d qwxQ== X-Gm-Message-State: ALoCoQmIKGxYIvdUmBKuSzIfYko0rZssxxUxaJWmo5fz6Wkm83HizZvLxGNtoM1kDOMUbeYCjgDI X-Received: by 10.194.143.109 with SMTP id sd13mr9798535wjb.70.1424354721127; Thu, 19 Feb 2015 06:05:21 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id kj8sm37538176wjc.29.2015.02.19.06.05.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Feb 2015 06:05:20 -0800 (PST) Message-ID: <54E5ED9E.9010408@multiplay.co.uk> Date: Thu, 19 Feb 2015 14:05:18 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Creating zpool on NVMe Disks takes forever References: <54E5BB12.3060707@fuckner.net> <54E5CF6E.5030906@multiplay.co.uk> <54E5D574.8020406@fuckner.net> In-Reply-To: <54E5D574.8020406@fuckner.net> Content-Type: multipart/mixed; boundary="------------020602090107060600080905" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 14:05:24 -0000 This is a multi-part message in MIME format. --------------020602090107060600080905 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 19/02/2015 12:22, Michael Fuckner wrote: > On 02/19/2015 12:56 PM, Steven Hartland wrote: >> Disable trim on init: >> sysctl vfs.zfs.vdev.trim_on_init=0 > this fixed it, thx! > > but why does it take >8h to trim 2x 400GB? Or is trimming handled > differently on NVMe than on HDD/SSD? Its very basic but you might want to give the attached patch a go and see if it reduces you TRIM time significantly? Regards Steve --------------020602090107060600080905 Content-Type: text/x-patch; name="nvd-delmaxsize.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="nvd-delmaxsize.patch" Index: sys/dev/nvd/nvd.c =================================================================== --- sys/dev/nvd/nvd.c (revision 278999) +++ sys/dev/nvd/nvd.c (working copy) @@ -287,8 +287,10 @@ nvd_new_disk(struct nvme_namespace *ns, void *ctrl disk->d_flags = 0; - if (nvme_ns_get_flags(ns) & NVME_NS_DEALLOCATE_SUPPORTED) + if (nvme_ns_get_flags(ns) & NVME_NS_DEALLOCATE_SUPPORTED) { disk->d_flags |= DISKFLAG_CANDELETE; + disk->d_delmaxsize = ((off_t)disk->d_sectorsize * ((off_t)1 << 32)); + } if (nvme_ns_get_flags(ns) & NVME_NS_FLUSH_SUPPORTED) disk->d_flags |= DISKFLAG_CANFLUSHCACHE; --------------020602090107060600080905-- From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 14:22:21 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E07DA404 for ; Thu, 19 Feb 2015 14:22:21 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (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 A8605C59 for ; Thu, 19 Feb 2015 14:22:21 +0000 (UTC) Received: by iecar1 with SMTP id ar1so9728984iec.11 for ; Thu, 19 Feb 2015 06:22:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/5MIxCwSbSeN9dcJz3/i5a38E6H5vtZ/8OahMK8pDYM=; b=lwoJeaFUwwexoM2t2Egmsq6QaDzvdZ6kLpq0EbyoC/SZZO1ObeXxZRLL4OUJ1HRxjV Z0N/NjQ/cFFWzeGSkeQWj+HZiVIwei6ybw260gKFttFSObU79kFBgw38+CwUNRDJgqjT KIdbnIl8yycx6azHc0mBNdlk7zADpLQEjq92T1HXBM7eDxyy4vJurdbiZNX+P8jLrdcD MQzBr+XOxl7SMXtuc7fh9zLxAA4NBBlm1oLfX0X8mTzDWbJ+V9felf55OYmEnEu5KIlm u3KYjq9j1xPjP/N9DrM9Nv2W5JLp4gMHpvpegW5a+BYRBXCB5tosHXBS/h6AX8vPFIf1 x+8w== X-Gm-Message-State: ALoCoQnOJnRZs1DKTEaI3bHbr2eoy3tuWk5Q8tV4hMQdAVQcHtT2oiakBR4A2L8xJY4lSNVTVGHE X-Received: by 10.42.77.9 with SMTP id g9mr6370331ick.78.1424355740328; Thu, 19 Feb 2015 06:22:20 -0800 (PST) Received: from kateleycoimac.local ([63.231.252.189]) by mx.google.com with ESMTPSA id m7sm6127305iom.12.2015.02.19.06.22.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Feb 2015 06:22:19 -0800 (PST) Message-ID: <54E5F19A.3080804@kateley.com> Date: Thu, 19 Feb 2015 08:22:18 -0600 From: Linda Kateley User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Creating zpool on NVMe Disks takes forever References: <54E5BB12.3060707@fuckner.net> <54E5CF6E.5030906@multiplay.co.uk> <54E5D574.8020406@fuckner.net> 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 14:22:22 -0000 On 2/19/15 7:02 AM, Tom Evans wrote: > On Thu, Feb 19, 2015 at 12:22 PM, Michael Fuckner wrote: >> On 02/19/2015 12:56 PM, Steven Hartland wrote: >>> Disable trim on init: >>> sysctl vfs.zfs.vdev.trim_on_init=0 >> this fixed it, thx! >> >> but why does it take >8h to trim 2x 400GB? Or is trimming handled >> differently on NVMe than on HDD/SSD? > TRIM/UNMAP is simply an SATA/SCSI command that is sent to a device. > What the device does when it gets that command is up to the controller > and firmware on the device. It would be nice to know what nvme you have so we know that the firmware for this particular one will be handled poorly? > > Cheers > > Tom > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" -- Linda Kateley Kateley Company Skype ID-kateleyco http://kateleyco.com From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 17:24:07 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18F59576 for ; Thu, 19 Feb 2015 17:24:07 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (using TLSv1.2 with cipher DHE-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 9CEBE350 for ; Thu, 19 Feb 2015 17:24:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1424366617; l=1037; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date; bh=UDEWKPaWLORujI9E7/WvHYjJSw70IOWqPwIlIFJ6/hc=; b=GRedu5vfGypFzDcN0HIdfgcytET/QCuuxks14oK9i4qjqdYdN3ItfZGUJ9RTLqlaD2F GOx8+rHtcrSEesB1K6wkCeLRHTs+Mm+2UmqTRLrVITBnqCH4LJRmbwAMJGxjvrEOcD/Vk IM32cOQOddb1qO2x8+sca9OlQEOfeqcaRCM= X-RZG-AUTH: :IWUHfUGtd9+4Du6KUGxoqde+AFhxnvkTDzh0c7ueojHnW/eNeq6Kp+QhHthC/P//Lh5ODL9FqzyNNUxt0AH1XMoM3yHFZvvKg1MBwQ== X-RZG-CLASS-ID: mo00 Received: from localhost.localdomain (bras-pool-3.wtnet.de [IPv6:2a02:2028:22a:8241:e8b:fdff:fe76:e463]) by smtp.strato.de (RZmta 37.3 AUTH) with ESMTPSA id j00bc8r1JHNbEuZ (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) for ; Thu, 19 Feb 2015 18:23:37 +0100 (CET) Message-ID: <54E61C18.8070101@fuckner.net> Date: Thu, 19 Feb 2015 18:23:36 +0100 From: Michael Fuckner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Creating zpool on NVMe Disks takes forever References: <54E5BB12.3060707@fuckner.net> <54E5CF6E.5030906@multiplay.co.uk> <54E5D574.8020406@fuckner.net> <54E5F19A.3080804@kateley.com> In-Reply-To: <54E5F19A.3080804@kateley.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 17:24:07 -0000 On 02/19/2015 03:22 PM, Linda Kateley wrote: > > On 2/19/15 7:02 AM, Tom Evans wrote: >> On Thu, Feb 19, 2015 at 12:22 PM, Michael Fuckner >> wrote: >>> On 02/19/2015 12:56 PM, Steven Hartland wrote: >>>> Disable trim on init: >>>> sysctl vfs.zfs.vdev.trim_on_init=0 >>> this fixed it, thx! >>> >>> but why does it take >8h to trim 2x 400GB? Or is trimming handled >>> differently on NVMe than on HDD/SSD? >> TRIM/UNMAP is simply an SATA/SCSI command that is sent to a device. >> What the device does when it gets that command is up to the controller >> and firmware on the device. > It would be nice to know what nvme you have so we know that the firmware > for this particular one will be handled poorly? It is 2x Intel P3700 (400GB, PCIe Card, FW: 8DV10130 and Bootloader 8B1B012D)- don't know how to extract this data in FreeBSD root@s4l:~ # nvmecontrol devlist nvme0: INTEL SSDPEDMD400G4 nvme0ns1 (381554MB) nvme1: INTEL SSDPEDMD400G4 nvme1ns1 (381554MB) Regards, Michael! From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 19:26:36 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D2971C7 for ; Thu, 19 Feb 2015 19:26:36 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (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 CDE5760F for ; Thu, 19 Feb 2015 19:26:35 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3kp5WX1hFmzK9 for ; Thu, 19 Feb 2015 20:26:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1424373988; x=1426965989; bh=wRO xir7Vx59q2sEljGcHhqkOh0xc2LzUPyUe1FzPRWQ=; b=jdj8KZWlS/MTtkjExFH k7kp9hdXFdeJFM5VXqrhYpYU3SuiAZiKyKqnIVwIjpTO+sVgZgLqA9N55dZ/ITcY 9S3tjNxvDFQhQjYSnVoWs2qe8SbJ7OiKuRSqPgNiwh1ujzcrg8NS3iPnAFqbEgST t2u31M/I+IEZYOuOI61fEsNk= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id r2f7IgQKJXZN for ; Thu, 19 Feb 2015 20:26:28 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Thu, 19 Feb 2015 20:26:27 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3kp5WR6jMzzVZ for ; Thu, 19 Feb 2015 20:26:27 +0100 (CET) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Thu, 19 Feb 2015 20:26:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 19 Feb 2015 20:26:27 +0100 From: Mark Martinec To: freebsd-fs@freebsd.org Subject: Re: Creating zpool on NVMe Disks takes forever Organization: J. Stefan Institute In-Reply-To: <54E61C18.8070101@fuckner.net> References: <54E5BB12.3060707@fuckner.net> <54E5CF6E.5030906@multiplay.co.uk> <54E5D574.8020406@fuckner.net> <54E5F19A.3080804@kateley.com> <54E61C18.8070101@fuckner.net> Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.5 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:26:36 -0000 >>>> On 02/19/2015 12:56 PM, Steven Hartland wrote: >>>>> Disable trim on init: >>>>> sysctl vfs.zfs.vdev.trim_on_init=0 >>>> this fixed it, thx! >>>> >>>> but why does it take >8h to trim 2x 400GB? Or is trimming handled >>>> differently on NVMe than on HDD/SSD? >>> TRIM/UNMAP is simply an SATA/SCSI command that is sent to a device. >>> What the device does when it gets that command is up to the >>> controller >>> and firmware on the device. The default of vfs.zfs.vdev.trim_on_init = 1 can be counterproductive in case of enabling encryption on a device. The FreeBSD handbook for example states: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html > 4. Create the New File System > > Next, format the device with the UFS file system and mount it > on an existing mount point: > # dd if=/dev/random of=/dev/da2.eli bs=1m > # newfs /dev/da2.eli > # mount /dev/da2.eli /private So after waiting for hours to populate the disk surface with random bytes, creating a ZFS pool out of it can ditch all the effort and possibly rewrite it with zeros before creating the pool. It should be documented to turn vfs.zfs.vdev.trim_on_init off in the above case. Mark From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 19:44:24 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF81D70B for ; Thu, 19 Feb 2015 19:44:24 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D18B684A for ; Thu, 19 Feb 2015 19:44:24 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 9D47C24E45; Thu, 19 Feb 2015 11:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1424375063; x=1424389463; bh=dXGzfbxYPlMPGC4wwtDZtm37h1hKVVvjYQUL73MxKOA=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=gcNMwvpaySmdVb5Gg1FsTUat6jNVVpe5dfNILT+/nYiFngGmwCma8rL7vsnsxpWqQ dNaYAILnfG7iehey3OjXFa9Zr2HvmBpgL9QqrD8zfNllITGwUZwVF+gUJM2AsXX1vY kH3XY42mpdmDVGK7g1iLU3WeuO5fndzkskXIJCHg= Message-ID: <54E63D17.4000006@delphij.net> Date: Thu, 19 Feb 2015 11:44:23 -0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Mark Martinec , freebsd-fs@freebsd.org Subject: Re: Creating zpool on NVMe Disks takes forever References: <54E5BB12.3060707@fuckner.net> <54E5CF6E.5030906@multiplay.co.uk> <54E5D574.8020406@fuckner.net> <54E5F19A.3080804@kateley.com> <54E61C18.8070101@fuckner.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:44:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/19/15 11:26, Mark Martinec wrote: >>>>> On 02/19/2015 12:56 PM, Steven Hartland wrote: >>>>>> Disable trim on init: sysctl vfs.zfs.vdev.trim_on_init=0 > >>>>> this fixed it, thx! >>>>> >>>>> but why does it take >8h to trim 2x 400GB? Or is trimming >>>>> handled differently on NVMe than on HDD/SSD? >>>> TRIM/UNMAP is simply an SATA/SCSI command that is sent to a >>>> device. What the device does when it gets that command is up >>>> to the controller and firmware on the device. > > > The default of vfs.zfs.vdev.trim_on_init = 1 can be > counterproductive in case of enabling encryption on a device. The > FreeBSD handbook for example states: > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html Encrypted > GEOM providers does not support TRIM (neither pass-through nor random initialization) right now, so this doesn't matter, at least not yet. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.1 (FreeBSD) iQIcBAEBCgAGBQJU5j0TAAoJEJW2GBstM+nsXJEP/3aT2VBSvBgB7m08STuv4PB6 7HHxb6a8MmSy94QGr19I3z+LaT3iIUjts/mncFyoatjYbRhd0DSiB4GUlnGr4PfK X7Yf9hVFFyBA6JaOWUF1HSIq7ErXZjWwVRuRSjx4nxBv5h+4NedMfhrMOdJFHj/P E9LzOUVwO1Chx0JjOFtf/U+72kbl75cyt/4eTo9WdTRn4k6JubedOBb5Q7AiXcq3 mROmNBwnD96s5zpx/9CjZ3fa8I7lQ14CWG6ca3MRRJlyg8ugfeGmJy6az8UOCZ/z Nld16RFetK1quWiat+xiLTHAopF+5Wc6PGjOG092nsy8uo0ITJMcJE1gvadiOr73 r7d50vDtiDYCE8V/lR+TtKB2j8vuU1iDKf3E4thdmlwpWIb09gsLvm6hVhNf6Wok 4hhJm4kRDiaBj4La30zCmqx0/xi01XIL4IiKH3UXRI/Gjty0+fhg0SNtrXisZjSD qBEeCgHoJ6BtC0kMHh70dmSgN41ElmqlA2SFXr+kJQY8Td68Cad0ZD7J2Jez4PgU jQ4OzqVvnY1KhxBiaAGcNCdRGdgC8jzxwenGhUSBjPkBcconTjvu6itEDZCfWLAk W5L7lFGf+CbvWF2ns/eu1OvCfQRIIX8i2m0mZk9yFDebSFTZkgPx0QC8B1NbZg1f bZU5SFZ04EOYu04LVwx4 =juXu -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 10:20:03 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5073EB4F for ; Fri, 20 Feb 2015 10:20:03 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (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 1E70E252 for ; Fri, 20 Feb 2015 10:20:03 +0000 (UTC) Received: by iecar1 with SMTP id ar1so6811154iec.0 for ; Fri, 20 Feb 2015 02:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=Sijqlx2y8SN4IAxL2UquJQmpI4nxGomZiLHot0Tg5lQ=; b=0t2rL8HQvBt+2AJ6h0KmmzzehXaZfdTed0l+nTQcyIXszeDI71wXTpkXpqXpeNRaux OEd1JaV9YHimtVy1I5BY6wf3fV6c5+1BWpDBYPyM9bLFo0fZjoHQ3mWQ7sLpnkJCO+zU GO23kbJ5ywunw+ujVtWfK1oQx55+2ckI9ccr55gENuDfp3svIgv14BV6gjCOL9S9ZRD+ J89i2oIsMFuDUnfBXBBuuR1X+PGCFmBWGx0Ez5cSbry/s0w0hUb/CSyofjIl9YCwsocY VhRy9gmujD3/DdUTi9inAmNSv/TyX/3+qlFzKyi5Rp8gFmLvn1BFfYwi0cq3aRPRb9Tv +Msg== MIME-Version: 1.0 X-Received: by 10.107.15.96 with SMTP id x93mr8466613ioi.75.1424427602267; Fri, 20 Feb 2015 02:20:02 -0800 (PST) Received: by 10.107.14.199 with HTTP; Fri, 20 Feb 2015 02:20:02 -0800 (PST) In-Reply-To: <54E63D17.4000006@delphij.net> References: <54E5BB12.3060707@fuckner.net> <54E5CF6E.5030906@multiplay.co.uk> <54E5D574.8020406@fuckner.net> <54E5F19A.3080804@kateley.com> <54E61C18.8070101@fuckner.net> <54E63D17.4000006@delphij.net> Date: Fri, 20 Feb 2015 10:20:02 +0000 Message-ID: Subject: Re: Creating zpool on NVMe Disks takes forever From: Tom Evans Cc: FreeBSD FS Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 10:20:03 -0000 On Thu, Feb 19, 2015 at 1:33 PM, Steven Hartland wrote: > Technically is not TRIM / UNMAP its BIO_DELETE which is translated by the > relevant device driver to the format the device understands. > > For SCSI this can be TRIM, UNMAP, WS or ZERO, for ATA this can be CFA_ERASE > or TRIM and for NVMe this is a Deallocate. > > One reason why it might be slow is I don't see NVMe configuring geom > d_delmaxsize, which if the case will force the "TRIM" to be split into > single sector deallocation requests. So "zfs_trim_on_init" doesn't require TRIM, it simply ensures it has wiped all data regardless of what the device supports. On Thu, Feb 19, 2015 at 7:44 PM, Xin Li wrote: > Encrypted GEOM providers does not support TRIM (neither pass-through > nor random initialization) right now, so this doesn't matter, at least > not yet. Given the above, doesn't this mean that encrypted geoms will be erased block by block on init, regardless of whether they can TRIM or not. Cheers Tom From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 10:28:38 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE00CDC1 for ; Fri, 20 Feb 2015 10:28:38 +0000 (UTC) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (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 4FE79358 for ; Fri, 20 Feb 2015 10:28:37 +0000 (UTC) Received: by wesw62 with SMTP id w62so4719523wes.9 for ; Fri, 20 Feb 2015 02:28:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VYtLp+ER/2Mefyyl/iy2fho5nK1gDuPTsENhbZjRJZY=; b=XnqlAdfZ2yWIiwE3/s09Lwg5i4c6BJgUB9Fih+cvyXWPuQ1GbzXvXpIrPes4y+1yIL xPPHVeqRktMMVDYSQlPVEB7fQDTR8V+jcV0NqwcP26PwAsMo30i/EMD6P+90JCtLWy5W dC7x+xtko94VVXK5DKAnpfyNKkrGmDu/GikS0TvW8ao+Dt1ZZjmvTYUHohx/moL0cz0P goPxN4FxZNX7e7nZvnroq269KgCA90kV5ozcsbziRdQqi6JX+ma+6jHkUO8VDBMezOaM t4OCjuFkzEXZW+UYX9QyfNwBQOe68zGIJVB/7FmNldspwFJ50rcwCNVe49oxbHDCUHhN VwbA== X-Gm-Message-State: ALoCoQkpwDQwNOZPC5NsiBiVv/Dm+yVcmV7z09JVIJonDyUCQB29q43UoHZhMdkXTRLf5jXJLsg+ X-Received: by 10.194.185.9 with SMTP id ey9mr17426218wjc.135.1424428109017; Fri, 20 Feb 2015 02:28:29 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id fo9sm1720462wib.16.2015.02.20.02.28.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Feb 2015 02:28:28 -0800 (PST) Message-ID: <54E70C49.80501@multiplay.co.uk> Date: Fri, 20 Feb 2015 10:28:25 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Creating zpool on NVMe Disks takes forever References: <54E5BB12.3060707@fuckner.net> <54E5CF6E.5030906@multiplay.co.uk> <54E5D574.8020406@fuckner.net> <54E5F19A.3080804@kateley.com> <54E61C18.8070101@fuckner.net> <54E63D17.4000006@delphij.net> 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 10:28:38 -0000 On 20/02/2015 10:20, Tom Evans wrote: > On Thu, Feb 19, 2015 at 1:33 PM, Steven Hartland > wrote: >> Technically is not TRIM / UNMAP its BIO_DELETE which is translated by the >> relevant device driver to the format the device understands. >> >> For SCSI this can be TRIM, UNMAP, WS or ZERO, for ATA this can be CFA_ERASE >> or TRIM and for NVMe this is a Deallocate. >> >> One reason why it might be slow is I don't see NVMe configuring geom >> d_delmaxsize, which if the case will force the "TRIM" to be split into >> single sector deallocation requests. > So "zfs_trim_on_init" doesn't require TRIM, it simply ensures it has > wiped all data regardless of what the device supports. No it will process deletes if the underlying device supports it, not all do. > On Thu, Feb 19, 2015 at 7:44 PM, Xin Li wrote: >> Encrypted GEOM providers does not support TRIM (neither pass-through >> nor random initialization) right now, so this doesn't matter, at least >> not yet. > Given the above, doesn't this mean that encrypted geoms will be erased > block by block on init, regardless of whether they can TRIM or not. > Nope, last time I looked GELI it didn't support DELETE at all, so the requests would be ignored. Regards Steve From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 11:46:45 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B95AECAE for ; Fri, 20 Feb 2015 11:46:45 +0000 (UTC) Received: from forward5l.mail.yandex.net (forward5l.mail.yandex.net [IPv6:2a02:6b8:0:1819::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71BCDD3C for ; Fri, 20 Feb 2015 11:46:45 +0000 (UTC) Received: from smtp16.mail.yandex.net (smtp16.mail.yandex.net [95.108.252.16]) by forward5l.mail.yandex.net (Yandex) with ESMTP id AD835C410C7 for ; Fri, 20 Feb 2015 14:46:41 +0300 (MSK) Received: from smtp16.mail.yandex.net (localhost [127.0.0.1]) by smtp16.mail.yandex.net (Yandex) with ESMTP id 5746E6A00EB for ; Fri, 20 Feb 2015 14:46:41 +0300 (MSK) Received: from host52-157-155-90.butovo.com (host52-157-155-90.butovo.com [90.155.157.52]) by smtp16.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id YCVRSyW5Yr-keuuPOVb; Fri, 20 Feb 2015 14:46:40 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1424432801; bh=cxSXwpNAt8UZF8vpFgexKOHSgPImU8gUyGDE+6RIIkY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=sRG2rRp4aE+WjpP5gDoJz+2MPfbPSAhWhTV1S0W/+bj+hih8eZuevEdplXq40Mk6R ofXbTmXzumKcOukZScbXvf8RhXcbQLlkTo/qrvSsz/uVqAdCLHd0sz0Eh7PRpr1XXX smWDQukkYi7TqpkwxVntTeim6kyO/EZKmmq+1024= Authentication-Results: smtp16.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <54E71E20.8080303@yandex.ru> Date: Fri, 20 Feb 2015 14:44:32 +0300 From: "Ilya A. Arkhipov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Disable zfs prefetch by default Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 11:46:45 -0000 Hi All, We have zfs prefetch enabled by default with > 4GB, but I didn't seen any case for using it, and all tuning guide saying to disable it. Maybe we disable zfs prefetch by default ? Or could you please provide why it needed. Thanks in advance. -- With Best Regards, Ilya A. Arkhipov From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 11:57:27 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 852806B for ; Fri, 20 Feb 2015 11:57:27 +0000 (UTC) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (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 1CB69E26 for ; Fri, 20 Feb 2015 11:57:26 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id b13so12743387wgh.0 for ; Fri, 20 Feb 2015 03:57:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=H50m0RBIbKjGYXFT3TgFNyg1Y5dlGSxjtX2OspqEwCU=; b=HgMI5YIu2cGR7zhp0ZhctPkfL/vUqw18nNaBriy5nXSuXJSyjprddgkVhUkmM9QH8q 8NV3FptSOx80LFlO/Xp0clQmQ0y8MQThvIMM6FENMfBvq38zT5KS3waYM1Hovjo5Rltx 3nSJRL9fsI5AoGpTN5BbrWLhHcXTqoU+QOnHjMY0s3GFPRVOnjOtkIxI/KJ+Jcx3umF0 77LlM74lnlyT1f6MhjLOdeQI2A6PIP+9CRU6z9AFAjI8m5zgkgN+HqzcZfm/BuOgcU2B QbbJU05i7ylQQyAKce1uZd0kYzQrgEXs5xrdO8SrwrQ0YfijmnPeayNkfSSLSBagW8xp 3CJg== X-Gm-Message-State: ALoCoQkgvi4eh4aTeiQrFjYFaAIIvt037qEY7KkEQcLJ1Erg/os1NxdRgNu8vXGHgxijga9QDBZU X-Received: by 10.194.241.197 with SMTP id wk5mr1230152wjc.44.1424433439389; Fri, 20 Feb 2015 03:57:19 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id x6sm41751886wjf.24.2015.02.20.03.57.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Feb 2015 03:57:18 -0800 (PST) Message-ID: <54E7211E.1070803@multiplay.co.uk> Date: Fri, 20 Feb 2015 11:57:18 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Disable zfs prefetch by default References: <54E71E20.8080303@yandex.ru> In-Reply-To: <54E71E20.8080303@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 11:57:27 -0000 Most of that advice is just FUD. On 20/02/2015 11:44, Ilya A. Arkhipov wrote: > Hi All, > > We have zfs prefetch enabled by default with > 4GB, but I didn't seen > any case for using it, and all tuning guide saying to disable it. > > Maybe we disable zfs prefetch by default ? Or could you please provide > why it needed. > > Thanks in advance. > From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 12:53:02 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15F3B979 for ; Fri, 20 Feb 2015 12:53:02 +0000 (UTC) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) (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 C702F63E for ; Fri, 20 Feb 2015 12:53:01 +0000 (UTC) Received: from [78.35.156.159] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YOn4f-0005d4-9S; Fri, 20 Feb 2015 13:52:53 +0100 Date: Fri, 20 Feb 2015 13:53:00 +0100 From: Fabian Keil To: "Ilya A. Arkhipov" Subject: Re: Disable zfs prefetch by default Message-ID: <66c5011b.0fcc09f9@fabiankeil.de> In-Reply-To: <54E71E20.8080303@yandex.ru> References: <54E71E20.8080303@yandex.ru> Reply-To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/uyr9CYr8H=VxInaCrbfuAtz"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 12:53:02 -0000 --Sig_/uyr9CYr8H=VxInaCrbfuAtz Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Ilya A. Arkhipov" wrote: > We have zfs prefetch enabled by default with > 4GB, but I didn't seen=20 > any case for using it, and all tuning guide saying to disable it. Which tuning guides are you referring to? > Maybe we disable zfs prefetch by default ? Or could you please provide=20 > why it needed. Whether or not prefetching is useful depends on the workload and the setup. If you doubt that the prefetch default is useful for your workload (for example because your systems mainly do small "random" reads from "random" files), you can easily test this by disabling prefetching for a while. If this is too much work (or if no difference can be measured), the default is probably fine. Fabian --Sig_/uyr9CYr8H=VxInaCrbfuAtz Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlTnLiYACgkQBYqIVf93VJ1lQACgyWFW051g5fIETiUbLJI5EgCX wsUAn0bhu3VQHmU21DZchVoWcmIKDMle =K0pp -----END PGP SIGNATURE----- --Sig_/uyr9CYr8H=VxInaCrbfuAtz-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 13:30:04 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC1303A3 for ; Fri, 20 Feb 2015 13:30:04 +0000 (UTC) Received: from forward3h.mail.yandex.net (forward3h.mail.yandex.net [IPv6:2a02:6b8:0:f05::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 802929FF for ; Fri, 20 Feb 2015 13:30:04 +0000 (UTC) Received: from web18h.yandex.ru (web18h.yandex.ru [84.201.186.47]) by forward3h.mail.yandex.net (Yandex) with ESMTP id 207AE1362D3A for ; Fri, 20 Feb 2015 16:29:26 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web18h.yandex.ru (Yandex) with ESMTP id AE0294F61593; Fri, 20 Feb 2015 16:29:26 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1424438966; bh=xwsPfmonLqvZvt5FGFwk7/PH5MPzCOm8mwhqlqDEa04=; h=From:To:In-Reply-To:References:Subject:Date; b=YiHO4+gNTyXqtN+132xvIKFdt3kxiaPog/WF+tSaGitETO2TbGERVSnT2JXhBBm+Z mVuU97q1nNET6SwRPz3tIv06phGC6/8hO3SKDzqraG4JAXWsAjCCH9V/PFEcJuKT8x J/kSBjTDj766Lsz84LNO3ZWsQAZHjT50/hd5KASc= Received: by web18h.yandex.ru with HTTP; Fri, 20 Feb 2015 16:29:26 +0300 From: Ilya A. Arkhipov To: "freebsd-fs@freebsd.org" In-Reply-To: <66c5011b.0fcc09f9@fabiankeil.de> References: <54E71E20.8080303@yandex.ru> <66c5011b.0fcc09f9@fabiankeil.de> Subject: Re: Disable zfs prefetch by default MIME-Version: 1.0 Message-Id: <614751424438966@web18h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 20 Feb 2015 16:29:26 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 13:30:04 -0000 20.02.2015, 15:52, "Fabian Keil" : > "Ilya A. Arkhipov" wrote: >> We have zfs prefetch enabled by default with > 4GB, but I didn't seen >> any case for using it, and all tuning guide saying to disable it. > > Which tuning guides are you referring to? This one https://wiki.freebsd.org/ZFSTuningGuide >> Maybe we disable zfs prefetch by default ? Or could you please provide >> why it needed. > > Whether or not prefetching is useful depends on the workload > and the setup. > > If you doubt that the prefetch default is useful for your workload > (for example because your systems mainly do small "random" reads > from "random" files), you can easily test this by disabling prefetching > for a while. > > If this is too much work (or if no difference can be measured), > the default is probably fine. > > Fabian Actualy on all my servers(more 300 ^_^), I've disable prefetch because on all have the same issue: http://i.imgur.com/aJNCiBK.png http://i.imgur.com/Di3FuWw.png http://i.imgur.com/uunH1k8.png http://i.imgur.com/vjYiB2K.png -- With Best Regards, Ilya A. Arkhipov From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 13:34:44 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 887C9B62 for ; Fri, 20 Feb 2015 13:34:44 +0000 (UTC) Received: from mail1.postbank.bg (mx.postbank.bg [195.242.126.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.postbank.bg", Issuer "GeoTrust DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FE10AED for ; Fri, 20 Feb 2015 13:34:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; d=postbank.bg; s=mail; c=relaxed/relaxed; q=dns/txt; i=@postbank.bg; t=1424438369; x=1427030369; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8aCnrMXZUS0RMHjqhTLgO+gI9JUcmw9llhunPEyw/cc=; b=QbAf8aCC93raG3zsMDzRRgwEsWuv4E2rlf/noJf2FmXicOHorcp40+6LWksLnZ6p DB0a+fvuCljPxd+lqE2iBtpRguPZA0Y7Hnns0tFC+g9LGwbUhwm1oExkNnPXLYjt iFpIyQIS4CpypBYNMO5ShnFGHqXKIYm8XX8uyFp53pY=; X-AuditID: ac100165-f79f86d000002fb1-75-54e73461eb83 Received: from sofdc01excv14.postbank.bg ( [10.1.129.37]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail1.postbank.bg (Eurobank AD BG Outbound mail system) with SMTP id 5D.BC.12209.16437E45; Fri, 20 Feb 2015 15:19:29 +0200 (EET) From: "Ivailo A. Tanusheff" To: "freebsd-fs@freebsd.org" Subject: ZVOL and snapshots length problem Thread-Topic: ZVOL and snapshots length problem Thread-Index: AdBND6RMju0eZwL0REa1ABKJVnnOtw== Date: Fri, 20 Feb 2015 13:19:28 +0000 Message-ID: <1422065A4E115F409E22C1EC9EDAFBA42214513E@sofdc01exc02.postbank.bg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.31] MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAKsWRmVeSWpSXmKPExsXCxdioqpto8jzEYMJ9bYtjj3+yOTB6zPg0 nyWAMaqB0SYxLy+/JLEkVSEltTjZVik6IL+4JCkxLztWwSWzODknMTM3tUhJITPFVslYSaEg JzE5NTc1r8RWKbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++taWJha6hoq2SFMtVJT NjRO+MqecXJxL1PBLueKh583MDcwHrXuYuTgkBAwkTh8yKWLkRPIFJO4cG89WxcjF4eQwBwm iYY1J5lAEmxANdvm7gGzRQRMJX79W8AGYgsLaEm87nnBBhHXl+jquckCYetJ3Onbzwhiswio SsxpXgIW5xXwl5h0uB/MZgRa9v3UGrCZzALiEreezGeCOEJAYsme88wQtqjEy8f/WCFsWYlv B/4xQtTnS1yY8J0JYqagxMmZT1gmMArOQjJqFpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznw mAlZfAEj+ypGyeL8tJRkA8NgX/cyA0O9AmjM6SWlb2IERvwaAcbUHYwvrjgdYhTgYFTi4a2Y /ixEiDWxrLgy9xCjBAezkgivp8LzECHelMTKqtSi/Pii0pzU4kOMVcDQmcgsJZqcD0xGeSXx hiYGhqYmRoYWBmYWplQRVhLnjV30NERIIB2Y8rJTUwtSi2CWM3FwSjUwiq87HH7H/uKqhYd2 3ZyT/+vQ5bBUtanlbwxuN1x5eOu1+WSxsi2/9dwn9Mkpqi1t/a47/czfB6GuPyIabC9Lacut +50kcF9I4aRMiq+neb5fod3G+FanjeaMh3Z7zLx34urGHR27xWZFXrnauGRpybF59yfNFr7e Yji59GJ3iMLBTsVUp3ePdyuxFGckGmoxFxUnAgCp0C+eUwMAAA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 13:34:44 -0000 Dear all, I have some trouble creating and manipulating ZVOL on my server. I am using= FreeBSD 10 and I am creating a little bit sophisticated structure, where I= create several file systems and volumes inside them for easy manipulation a= nd snapshot management. An example structure is: / / / / Whenever my ZVOL path exceeds 63 characters, both when creating volume or sn= apshot, I receive this error in my messages log: Feb 20 13:05:04 FreeBSD kernel: g_dev_taste: make_dev_p() failed (gp->name= =3Dzvol/TANK/Bank system/Core/DB@Daily_operations_2015-02-20-13:05, error=3D= 22) Feb 20 13:05:04 FreeBSD kernel: g_dev_taste: make_dev_p() failed (gp->name= =3Dzvol/TANK/Bank system/Core/FS@Daily_operations_2015-02-20-13:05, error=3D= 22) Feb 20 13:05:05 FreeBSD kernel: g_dev_taste: make_dev_p() failed (gp->name= =3Dzvol/TANK/Bank system/Core/Report@Daily_operations_2015-02-20-13:05, erro= r=3D63) Feb 20 13:10:05 FreeBSD kernel: g_dev_taste: make_dev_p() failed (gp->name= =3Dzvol/TANK/Bank system/Core/DB@Daily_operations_2015-02-20-13:10, error=3D= 22) Feb 20 13:10:05 FreeBSD kernel: g_dev_taste: make_dev_p() failed (gp->name= =3Dzvol/TANK/Bank system/Core/FS@Daily_operations_2015-02-20-13:10, error=3D= 22) Feb 20 13:10:05 FreeBSD kernel: g_dev_taste: make_dev_p() failed (gp->name= =3Dzvol/TANK/Bank system/Core/Report@Daily_operations_2015-02-20-13:10, erro= r=3D63) As far as I digged into it this is due to impossibility of creation of /dev= /zvol/... pointing to that volume or snapshot, while the volume/snapshot is= still visible in the zfs list tree, although I am not quite sure I can use= it. Is there any way to fix this behavior or this is an implementation bug, not= described in the manual? If I create shorter names the problem disappears, but this is contra version= of what I needed, so it is a not acceptable solution. Regards, Ivailo Tanusheff Head of Demand and Project management department Information Technologies Division Disclaimer: This communication is confidential. If you are not the intended recipient, y= ou are hereby notified that any disclosure, copying, distribution or taking= any action in reliance on the contents of this information is strictly proh= ibited and may be unlawful. If you have received this communication by mista= ke, please notify us immediately by responding to this email and then delete= it from your system. Eurobank Bulgaria AD is not responsible for, nor endorses, any opinion, reco= mmendation, conclusion, solicitation, offer or agreement or any information= contained in this communication. Eurobank Bulgaria AD cannot accept any responsibility for the accuracy or co= mpleteness of this message as it has been transmitted over a public network.= If you suspect that the message may have been intercepted or amended, pleas= e call the sender. From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 16:23:20 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D1C243A for ; Fri, 20 Feb 2015 16:23:20 +0000 (UTC) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [46.17.166.21]) by mx1.freebsd.org (Postfix) with ESMTP id D2F762A1 for ; Fri, 20 Feb 2015 16:23:18 +0000 (UTC) Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.5/8.14.5) with ESMTP id t1KGCbXT046012; Fri, 20 Feb 2015 16:12:37 GMT (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id t1KGCbHv014659; Fri, 20 Feb 2015 16:12:37 GMT Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id t1KGCacu014655; Fri, 20 Feb 2015 16:12:36 GMT Date: Fri, 20 Feb 2015 16:12:36 GMT Message-Id: <201502201612.t1KGCacu014655@higson.cam.lispworks.com> From: Martin Simmons To: "Ivailo A. Tanusheff" In-reply-to: <1422065A4E115F409E22C1EC9EDAFBA42214513E@sofdc01exc02.postbank.bg> (ITanusheff@postbank.bg) Subject: Re: ZVOL and snapshots length problem References: <1422065A4E115F409E22C1EC9EDAFBA42214513E@sofdc01exc02.postbank.bg> Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 16:23:20 -0000 >>>>> On Fri, 20 Feb 2015 13:19:28 +0000, Ivailo A Tanusheff said: > > Dear all, > > I have some trouble creating and manipulating ZVOL on my server. I am using FreeBSD 10 and I am creating a little bit sophisticated structure, where I create several file systems and volumes inside them for easy manipulation and snapshot management. > An example structure is: > / / / / > > Whenever my ZVOL path exceeds 63 characters, both when creating volume or snapshot, I receive this error in my messages log: > Feb 20 13:05:04 FreeBSD kernel: g_dev_taste: make_dev_p() failed (gp->name=zvol/TANK/Bank system/Core/DB@Daily_operations_2015-02-20-13:05, error=22) > Feb 20 13:05:04 FreeBSD kernel: g_dev_taste: make_dev_p() failed (gp->name=zvol/TANK/Bank system/Core/FS@Daily_operations_2015-02-20-13:05, error=22) > Feb 20 13:05:05 FreeBSD kernel: g_dev_taste: make_dev_p() failed (gp->name=zvol/TANK/Bank system/Core/Report@Daily_operations_2015-02-20-13:05, error=63) > > Feb 20 13:10:05 FreeBSD kernel: g_dev_taste: make_dev_p() failed (gp->name=zvol/TANK/Bank system/Core/DB@Daily_operations_2015-02-20-13:10, error=22) > Feb 20 13:10:05 FreeBSD kernel: g_dev_taste: make_dev_p() failed (gp->name=zvol/TANK/Bank system/Core/FS@Daily_operations_2015-02-20-13:10, error=22) > Feb 20 13:10:05 FreeBSD kernel: g_dev_taste: make_dev_p() failed (gp->name=zvol/TANK/Bank system/Core/Report@Daily_operations_2015-02-20-13:10, error=63) > > As far as I digged into it this is due to impossibility of creation of /dev/zvol/... pointing to that volume or snapshot, while the volume/snapshot is still visible in the zfs list tree, although I am not quite sure I can use it. > > Is there any way to fix this behavior or this is an implementation bug, not described in the manual? > If I create shorter names the problem disappears, but this is contra version of what I needed, so it is a not acceptable solution. I think this is a limitation in FreeBSD device naming. error=22 is EINVAL, because you have a space in the name. error=63 is ENAMETOOLONG, because the name is longer than SPECNAMELEN (also 63 by coincidence). __Martin From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 19:15:13 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E238BA04 for ; Fri, 20 Feb 2015 19:15:13 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9EAB3A90 for ; Fri, 20 Feb 2015 19:15:13 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YOt2W-0002Hz-ES for freebsd-fs@freebsd.org; Fri, 20 Feb 2015 20:15:04 +0100 Received: from p4fddd00b.dip0.t-ipconnect.de ([79.221.208.11]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Feb 2015 20:15:04 +0100 Received: from christian.baer by p4fddd00b.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Feb 2015 20:15:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Christian Baer Subject: The magic of ZFS and NFS (2nd try) Date: Fri, 20 Feb 2015 20:11:10 +0100 Lines: 43 Message-ID: <4257601.p3oiXZFr4n@falbala.rz1.convenimus.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p4fddd00b.dip0.t-ipconnect.de User-Agent: KNode/4.14.2 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 19:15:14 -0000 Hi everyone! I've already asked this question (basically) in the questions list, but I didn't get anything that really helped me along. I am hoping to get a little further on this list. Using my search engines, I have found out that exporting a ZFS is a by picky. However I have found no general rules of what to do - yet. My file server is called obelix, my workstation falbala. Feel free to make fun of that fact. :-) obelix boots from an SSD. There is a raidz2 configured with 7 HDDs, mounted under /zfs/arc1. This is the main (basic, root) mount point of the ZFS pool and it is pretty much empty. There are other tanks I have defined and they are under /usr/archive/. The directory /usr/archive/ is of course still part of the SSD. When I set /usr/archive as an export in /etc/exports, I can mount that from falabala. I see all the subdirectories too - each of these are ZFS tanks. However, I cannot access the contents of the tanks. I've played around here a bit and there are two things that can happen: 1. I can dive into the directories but they look empty from falbala. 2. Access to the directories is refused completely. I don't remember what I did to get each of these results, so please don't ask. :-) Ok, so I read that I cannot export all ZFS mounts together like this and have to create an export for each seperately. Fine with me. :-) So I created and export to /usr/archive/shared which is the mount point of a ZFS tank. But if I try to mount that via NFS from falbala, the connection is denied completely. This is logged in /var/log/messages on obelix - without any reason however. Now it might be that I am just to dumb to understand the works of NFS and ZFS or I am just missing a piece of the puzzle. Can someone please give me a push, please? Regards, Chris From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 19:35:11 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB1A0E1F for ; Fri, 20 Feb 2015 19:35:11 +0000 (UTC) Received: from mail.ultra-secure.de (mail.ultra-secure.de [88.198.178.88]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 35999CD6 for ; Fri, 20 Feb 2015 19:35:10 +0000 (UTC) Received: (qmail 84269 invoked by uid 89); 20 Feb 2015 19:35:01 -0000 Received: from unknown (HELO ?192.168.1.200?) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 20 Feb 2015 19:35:01 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: The magic of ZFS and NFS (2nd try) From: Rainer Duffner In-Reply-To: <4257601.p3oiXZFr4n@falbala.rz1.convenimus.net> Date: Fri, 20 Feb 2015 20:34:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4257601.p3oiXZFr4n@falbala.rz1.convenimus.net> To: Christian Baer X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 19:35:11 -0000 > Am 20.02.2015 um 20:11 schrieb Christian Baer = : >=20 > Hi everyone! >=20 > I've already asked this question (basically) in the questions list, = but I=20 > didn't get anything that really helped me along. I am hoping to get a = little=20 > further on this list. >=20 > Using my search engines, I have found out that exporting a ZFS is a by=20= > picky. However I have found no general rules of what to do - yet. >=20 > My file server is called obelix, my workstation falbala. Feel free to = make=20 > fun of that fact. :-) >=20 > obelix boots from an SSD. There is a raidz2 configured with 7 HDDs, = mounted=20 > under /zfs/arc1. This is the main (basic, root) mount point of the ZFS = pool=20 > and it is pretty much empty. There are other tanks I have defined and = they=20 > are under /usr/archive/. The directory /usr/archive/ is of course = still part=20 > of the SSD. >=20 > When I set /usr/archive as an export in /etc/exports, I can mount that = from=20 > falabala. I see all the subdirectories too - each of these are ZFS = tanks.=20 > However, I cannot access the contents of the tanks. I've played around = here=20 > a bit and there are two things that can happen: >=20 > 1. I can dive into the directories but they look empty from falbala. > 2. Access to the directories is refused completely. >=20 > I don't remember what I did to get each of these results, so please = don't=20 > ask. :-) >=20 > Ok, so I read that I cannot export all ZFS mounts together like this = and=20 > have to create an export for each seperately. Fine with me. :-) >=20 > So I created and export to /usr/archive/shared which is the mount = point of a=20 > ZFS tank. But if I try to mount that via NFS from falbala, the = connection is=20 > denied completely. This is logged in /var/log/messages on obelix - = without=20 > any reason however. >=20 > Now it might be that I am just to dumb to understand the works of NFS = and=20 > ZFS or I am just missing a piece of the puzzle. Can someone please = give me a=20 > push, please? You must use the syntax of exports(5) also with zfs set sharenfs=3D AFAIK, you shouldn=E2=80=99t use /etc/exports to do zfs exports but the = above command If your hosts you export to are in your nfs-server=E2=80=99s /etc/hosts, = you will need to use the names they resolve to also in the = exports-statement. (Though that might be wrong - it was the case with Solaris, though). uids/gids should match, too, of course. Rainer= From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 20:15:03 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9835EDE for ; Fri, 20 Feb 2015 20:15:03 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 7E3EF151 for ; Fri, 20 Feb 2015 20:15:03 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id wo20so26115965obc.5 for ; Fri, 20 Feb 2015 12:15:02 -0800 (PST) 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 :content-transfer-encoding; bh=vSZYECQZLBmJicm0sJoN5egoCVWj6S2EAdNXZciZKAY=; b=AfEPJuoPi4SYzfW6HPfLyXOefIXOdoO6lAsMMo/fS4J6trhz1KK2CnI/Ia0YujFjfB FKWaAmugeDXlTuWADLyXFT1jpholI+XfYDtTbqK/4vm+nYjMaH82Xb52x/asZ5v2L1AY p6rKNumRZwIAi3g45pUaD5m+eH5t9LcLslUtdhQ8ZMuv0qvLQbyzkfbO5fCrNDVhZ0h7 mKvuASD0u2Vcpx4GTAJGIA8FoWRkulv4ZKCSA8iM/l6xlrVC9Lp2nSSByk6OHYncB7mH UrWK/Jh2LSqSGKpExT4sg4JHGM/mIq5JgcH6eu54BwMR/FIpdExeer2E8ukbIHFG0pjx 25kQ== MIME-Version: 1.0 X-Received: by 10.60.96.167 with SMTP id dt7mr7729131oeb.54.1424463302653; Fri, 20 Feb 2015 12:15:02 -0800 (PST) Received: by 10.60.140.199 with HTTP; Fri, 20 Feb 2015 12:15:02 -0800 (PST) Date: Fri, 20 Feb 2015 15:15:02 -0500 Message-ID: Subject: Zoned Commands ZBS/ZAC, Shingled SMR/SFS, ZFS From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 20:15:03 -0000 These may be of interest for possible integration... https://github.com/hgst/libzbc https://github.com/Seagate/SMR_FS-EXT4 Panel: Shingled Disk Drives=E2=80=94File System Vs. Autonomous Block Device http://storageconference.us/2014/Presentations/Panel4.Bandic.pdf http://storageconference.us/2014/Presentations/Panel4.Amer.pdf http://storageconference.us/2014/Presentations/Panel4.Novak.pdf ZFS on SMR Drives: Enabling Shingled Magnetic Recording (SMR) for Enterprises http://storageconference.us/2014/Presentations/Novak.pdf http://storageconference.us/2014/index.html http://storageconference.us/history.html From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 21:02:59 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C53FB6B3; Fri, 20 Feb 2015 21:02:59 +0000 (UTC) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 926089A4; Fri, 20 Feb 2015 21:02:59 +0000 (UTC) Received: by mail-oi0-f50.google.com with SMTP id v1so4752688oia.9; Fri, 20 Feb 2015 13:02:58 -0800 (PST) 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=0ZAhxCHvcwnEpkwf8mJ+siqh9/qJh+tljISgSgMbDbY=; b=HEyZonFIwzS44uopcQtXl2QaicqeShdXxYHbn9z0HFDlY0BePak3VkjO/rIYdezLzF ndOCit/2RaVP/4DBtrBxO+td6WAbINlXmQ47Ziqy660WR00kyVPqI2/k/73H4GM0bhZq /zHF2Z6xLOWoIOpFchwgQScughPDt/N4V/0x8iM1NDmQsVk3W7oqLL7lworpWzJCj23G lyv47tyenPn+pRaJki2Vw3O3V1wxAE5hlAk25UC9PUiZcF2wphS3KRD8hKRdqOhSLJxR 2iWGDAxViXG+hz7yhJ6B8w3BMPFHKUT70vgTjifnmAJL80MAUYvNeW0v2rEMjO4b3rjw mXsw== MIME-Version: 1.0 X-Received: by 10.60.102.41 with SMTP id fl9mr7847674oeb.33.1424466178584; Fri, 20 Feb 2015 13:02:58 -0800 (PST) Received: by 10.60.140.199 with HTTP; Fri, 20 Feb 2015 13:02:58 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Feb 2015 16:02:58 -0500 Message-ID: Subject: Re: Zoned Commands ZBS/ZAC, Shingled SMR/SFS, ZFS From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: zfs-devel@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 21:02:59 -0000 > On freebsd-fs: > ZFS on SMR Drives: Enabling Shingled Magnetic Recording (SMR) for Enterprises > http://storageconference.us/2014/Presentations/Novak.pdf Further references... ZFS Host-Aware_SMR http://open-zfs.org/w/images/2/2a/Host-Aware_SMR-Tim_Feldman.pdf libzbc - The Linux Foundation http://events.linuxfoundation.org/sites/events/files/slides/SMR-LinuxConUSA-2014.pdf http://www.snia.org/sites/default/files/Dunn-Feldman_SNIA_Tutorial_Shingled_Magnetic_Recording-r7_Final.pdf http://www.opencompute.org/wiki/Storage/Dev Initial ZAC support http://www.spinics.net/lists/linux-scsi/msg81545.html ZAC/ZBC Update http://www.spinics.net/lists/linux-scsi/msg80161.html From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 21:17:26 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B08D4AA6 for ; Fri, 20 Feb 2015 21:17:26 +0000 (UTC) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (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 837B5B53 for ; Fri, 20 Feb 2015 21:17:26 +0000 (UTC) Received: by quine.pinyon.org (Postfix, from userid 122) id 0EEB6160254; Fri, 20 Feb 2015 14:10:42 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 83B151601CF for ; Fri, 20 Feb 2015 14:10:39 -0700 (MST) Message-ID: <54E7A2CF.60804@pinyon.org> Date: Fri, 20 Feb 2015 14:10:39 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: The magic of ZFS and NFS (2nd try) References: <4257601.p3oiXZFr4n@falbala.rz1.convenimus.net> In-Reply-To: <4257601.p3oiXZFr4n@falbala.rz1.convenimus.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 21:17:26 -0000 On 02/20/15 12:11, Christian Baer wrote: > Hi everyone! > > I've already asked this question (basically) in the questions list, but I > didn't get anything that really helped me along. I am hoping to get a little > further on this list. > > Using my search engines, I have found out that exporting a ZFS is a by > picky. However I have found no general rules of what to do - yet. > > My file server is called obelix, my workstation falbala. Feel free to make > fun of that fact. :-) > > obelix boots from an SSD. There is a raidz2 configured with 7 HDDs, mounted > under /zfs/arc1. This is the main (basic, root) mount point of the ZFS pool > and it is pretty much empty. There are other tanks I have defined and they > are under /usr/archive/. The directory /usr/archive/ is of course still part > of the SSD. > > When I set /usr/archive as an export in /etc/exports, I can mount that from > falabala. I see all the subdirectories too - each of these are ZFS tanks. > However, I cannot access the contents of the tanks. I've played around here > a bit and there are two things that can happen: > > 1. I can dive into the directories but they look empty from falbala. > 2. Access to the directories is refused completely. > > I don't remember what I did to get each of these results, so please don't > ask. :-) > > Ok, so I read that I cannot export all ZFS mounts together like this and > have to create an export for each seperately. Fine with me. :-) > So I created and export to /usr/archive/shared which is the mount point of a > ZFS tank. But if I try to mount that via NFS from falbala, the connection is > denied completely. This is logged in /var/log/messages on obelix - without > any reason however. > > Now it might be that I am just to dumb to understand the works of NFS and > ZFS or I am just missing a piece of the puzzle. Can someone please give me a > push, please? Post your /etc/exports, and the nfs*_enable bits of /etc/rc.conf. And as Rainer noted you definitely need to check that uid/gid match on both server and client. You can quickly check that sharenfs=on via mount: root@terpsichore> mount | grep NFS system/export on /export (zfs, NFS exported, local, nfsv4acls) system/export/library on /export/library (zfs, NFS exported, local, nfsv4acls) system/export/usr on /export/usr (zfs, NFS exported, local, nfsv4acls) system/export/usr/obj on /export/usr/obj (zfs, NFS exported, local, nfsv4acls) system/export/usr/src on /export/usr/src (zfs, NFS exported, local, nfsv4acls) ssd1/poudriere/ports/default on /ssd1/poudriere/ports/default (zfs, NFS exported, local, nfsv4acls) system/usr/ports on /usr/ports (zfs, NFS exported, local, nosuid, nfsv4acls) system/usr/ports/distfiles on /usr/ports/distfiles (zfs, NFS exported, local, nosuid, nfsv4acls) /raid/library on /export/library (nullfs, NFS exported, local, nfsv4acls) /ssd1/poudriere/data/packages/stable-amd64-default on /export/packages (nullfs, NFS exported, local, nfsv4acls) Russell > Regards, > Chris > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 21:34:43 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 080FB70 for ; Fri, 20 Feb 2015 21:34:43 +0000 (UTC) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 BF516D52 for ; Fri, 20 Feb 2015 21:34:42 +0000 (UTC) Received: by mail-oi0-f44.google.com with SMTP id a3so4846621oib.3 for ; Fri, 20 Feb 2015 13:34:42 -0800 (PST) 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 :content-type; bh=OR7vddQvtR9leHHRN8us/oNV2G4zz5YTnQL7GZ4yPc0=; b=LIK+VR9vY5nwmIQ/eUsdt4X8cM8V2D/ACMCSYV88AnLFbqb0RtJhBb0x795hsMlUxP j41YYnrp+5EdnrCWHHlteDN6O2ysO5CcYoE+j/5sOe2giVodo2FoCKwXyLxAfR9OUJuy Jy7LL3tk7fI+pLEvl60SDi9uJa4EMH80fZkwX8YOa5se0S0ggvhsFiooIYa/gMl8KWfU LUMceLRJZt6e2jjbysuRlXgHIqNkZquu1Q3j/K23yqSdQOyZj+bvw6B2VLswhFrz3zkr Psh8kCI2UXthBfXxlVlJQlEEPfVhnSk1QcXiD27wErac2XtJLTHXoqvCeJcuzjeM5O6M Fhgw== MIME-Version: 1.0 X-Received: by 10.202.232.65 with SMTP id f62mr7620617oih.116.1424468082087; Fri, 20 Feb 2015 13:34:42 -0800 (PST) Received: by 10.60.140.199 with HTTP; Fri, 20 Feb 2015 13:34:42 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Feb 2015 16:34:42 -0500 Message-ID: Subject: Re: Zoned Commands ZBS/ZAC, Shingled SMR/SFS, ZFS From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 21:34:43 -0000 I typo ZBS in subject instead of correct ZBC, this MUA couldn't fix it on reply without breaking thread refs, sorry. From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 21:50:01 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2408635E for ; Fri, 20 Feb 2015 21:50:01 +0000 (UTC) Received: from smtp.atelo.org (atelo.org [198.100.144.64]) by mx1.freebsd.org (Postfix) with ESMTP id EF46CE89 for ; Fri, 20 Feb 2015 21:50:00 +0000 (UTC) Received: from coyotlan (cpe-76-88-16-9.san.res.rr.com [76.88.16.9]) by smtp.atelo.org (Postfix) with ESMTPSA id A137C759D27; Fri, 20 Feb 2015 13:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=atelo.org; s=mail; t=1424469044; bh=m1MXp6jvwKPPbM8eKDs+DpkljFnjYlCzVG2OM2v6L2w=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=JRdCrDbzlnig3Bsc9P63lg2h0RGK7uREfjdKOBNWWEK8T+PMzcI5v7j9lBytv+9ya bH08LCAgBMbuLyQ2ZaYUwizIAeoEkV9cyQev7ulf6Fa0KUX4Sil4jNeGEe6JSxV4o3 ZP9xwzBMjUIrMegJeEKmrxc7EGB/Eh3zulTfTGAo= Received: from localhost (coyotlan [local]); by coyotlan (OpenSMTPD) with ESMTPA id 8db773f6; Fri, 20 Feb 2015 21:49:52 +0000 (UTC) Date: Fri, 20 Feb 2015 13:49:52 -0800 From: =?utf-8?B?WMSrY8Oy?= To: krad Subject: Re: ZFS root set to readonly=on temporary at boot Message-ID: <20150220214952.GA13839@coyotlan.Tlalpan> References: <20150218191345.GA31812@coyotlan.Tlalpan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD FS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 21:50:01 -0000 On Thu, Feb 19, 2015 at 12:12:54PM +0000, krad wrote: > Check your bootfs and the / file system actually match up. Its quite easy > to get odd things happening if you have the bootfs set to a filesystem that > then has an fstab which then tells / is on another fs. Also check the > loader.conf on the bootfs. In my experiance its safer to have clean fstabs, > and nothing in the loader.conf (in relation to this) and just relay on the > bootfs pool property Thanks for the tips. I still could not figure it out though. My partition scheme is as follows: # gpart show => 34 3907029101 ada0 GPT (1.8T) 34 128 1 freebsd-boot (64K) 162 8388608 2 freebsd-swap (4.0G) 8388770 3898640365 3 freebsd-zfs (1.8T) with a bootcode installed by: # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 The bootfs property of the zpool seems to be set to the correct root: # zpool get bootfs zroot NAME PROPERTY VALUE SOURCE zroot bootfs zroot local # zfs list zroot NAME USED AVAIL REFER MOUNTPOINT zroot 2.16G 1.75T 509M / The /etc/fstab only lists the swap partition (and there are no other fstab files, nor any unmounted snapshot/partitions): # cat /etc/fstab /dev/label/swap none swap sw 0 0 My loader.conf appears to be required for the server to boot: # cat /boot/loader.conf zfs_load="YES" vfs.root.mountfrom="zfs:zroot" Also, the root is mounted in read/write when manually imported from another system: # zpool import -R /mnt zroot # zfs get readonly zroot NAME PROPERTY VALUE SOURCE zroot readonly off temporary Anyway, it is not that huge a problem, but it is quite inconvenient not to understand what could be the reason behind that. As far as I can tell, it may be related to the fact that my root was not created in its own dataset: # zfs list NAME USED AVAIL REFER MOUNTPOINT zroot 2.16G 1.75T 509M / zroot/ezjail 984M 1.75T 27K /usr/jails zroot/var 284M 1.75T 10.6M /var […] I might check that later on. Best, Xīcò From owner-freebsd-fs@FreeBSD.ORG Sat Feb 21 11:32:46 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D0499FD for ; Sat, 21 Feb 2015 11:32:46 +0000 (UTC) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) (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 DFE969D1 for ; Sat, 21 Feb 2015 11:32:45 +0000 (UTC) Received: from [78.35.175.151] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YP8Fd-0001Il-Ax for freebsd-fs@freebsd.org; Sat, 21 Feb 2015 12:29:37 +0100 Date: Sat, 21 Feb 2015 12:21:53 +0100 From: Fabian Keil To: freebsd-fs@freebsd.org Subject: Re: panic: solaris assert: rt->rt_space == 0 (0xe000 == 0x0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/range_tree.c, line: 153 Message-ID: <48e5e0b3.6c036ece@fabiankeil.de> In-Reply-To: <580853d0.0ab6eb7d@fabiankeil.de> References: <04f3092d.6fdfad8a@fabiankeil.de> <580853d0.0ab6eb7d@fabiankeil.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/1l/65pMCjgx1ZqnFqMysy8V"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 11:32:46 -0000 --Sig_/1l/65pMCjgx1ZqnFqMysy8V Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > Fabian Keil wrote: >=20 > > Using an 11.0-CURRENT based on r276255 I just got a panic > > after trying to export a certain ZFS pool: [...] > > The export triggered the same panic again, but with a different rt->rt_= space value: > >=20 > > panic: solaris assert: rt->rt_space =3D=3D 0 (0x22800 =3D=3D 0x0), file= : /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/range_tree.c, lin= e: 153 > >=20 > > I probably won't have time to scrub the pool and investigate this furth= er > > until next week. >=20 > With this patch and vfs.zfs.recover=3D1 the pool can be exported without = panic: > https://www.fabiankeil.de/sourcecode/electrobsd/range_tree_destroy-Option= ally-tolerate-non-zero-rt-r.diff [...] > Due to interruptions the scrubbing will probably take a couple of days. > ZFS continues to complain about checksum errors but apparently no > affected files have been found yet: The results are finally in: OpenZFS found nothing to repair but continues to complain about checksum errors, presumably in "<0xffffffffffffffff>:<0x0= >" which totally looks like a legit path that may affect my applications: fk@r500 ~ $zogftw zpool status -v 2015-02-21 12:06:29 zogftw: Executing: zpool status -v wde4=20 pool: wde4 state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: scrub repaired 0 in 134h55m with 0 errors on Sat Feb 21 12:00:47 20= 15 config: NAME STATE READ WRITE CKSUM wde4 ONLINE 0 0 795 label/wde4.eli ONLINE 0 0 3.11K errors: Permanent errors have been detected in the following files: <0xffffffffffffffff>:<0x0> fk@r500 ~ $zogftw export 2015-02-21 12:07:03 zogftw: No zpool specified. Exporting all external ones= : wde4 2015-02-21 12:07:03 zogftw: Exporting wde4 fk@r500 ~ $zogftw import 2015-02-21 12:07:13 zogftw: No pool name specified. Trying all unattached l= abels: wde4 2015-02-21 12:07:13 zogftw: Using geli keyfile /home/fk/.config/zogftw/geli= /keyfiles/wde4.key 2015-02-21 12:07:25 zogftw: 'wde4' attached 2015-02-21 12:08:07 zogftw: 'wde4' imported fk@r500 ~ $zogftw zpool status -v 2015-02-21 12:08:13 zogftw: Executing: zpool status -v wde4=20 pool: wde4 state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: scrub repaired 0 in 134h55m with 0 errors on Sat Feb 21 12:00:47 20= 15 config: NAME STATE READ WRITE CKSUM wde4 ONLINE 0 0 9 label/wde4.eli ONLINE 0 0 36 errors: Permanent errors have been detected in the following files: <0xffffffffffffffff>:<0x0> Exporting the pool still triggers the sanity check in range_tree_destroy(). Fabian --Sig_/1l/65pMCjgx1ZqnFqMysy8V Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlToak4ACgkQBYqIVf93VJ0yrwCgzbidsRGcuFt8mX8onui6gpHT nE8Ani9TN6O7/Eem0oVsrcVDtXJIlAzR =4xup -----END PGP SIGNATURE----- --Sig_/1l/65pMCjgx1ZqnFqMysy8V-- From owner-freebsd-fs@FreeBSD.ORG Sat Feb 21 17:34:31 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02356455 for ; Sat, 21 Feb 2015 17:34:31 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B0A54F54 for ; Sat, 21 Feb 2015 17:34:30 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YPDwf-0003qP-V8 for freebsd-fs@freebsd.org; Sat, 21 Feb 2015 18:34:26 +0100 Received: from p5b02295d.dip0.t-ipconnect.de ([91.2.41.93]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Feb 2015 18:34:25 +0100 Received: from christian.baer by p5b02295d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Feb 2015 18:34:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Christian Baer Subject: Re: The magic of ZFS and NFS (2nd try) Date: Sat, 21 Feb 2015 18:34:12 +0100 Lines: 39 Message-ID: <2437038.yvsE2IGTDZ@falbala.rz1.convenimus.net> References: <4257601.p3oiXZFr4n@falbala.rz1.convenimus.net> <54E7A2CF.60804@pinyon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p5b02295d.dip0.t-ipconnect.de User-Agent: KNode/4.14.2 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 17:34:31 -0000 Russell L. Carter wrote: > Post your /etc/exports, and the nfs*_enable bits of /etc/rc.conf. And > as Rainer noted you definitely need to check that uid/gid match on > both server and client. Pretty boring stuff... root@obelix:~ # cat /etc/exports V4: /usr/archive/Shared -alldirs -network 192.168.100/24 I reduced the shares to one for the time being. root@obelix:~ # mount /dev/ufs/root on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) /dev/ufs/var on /var (ufs, local, soft-updates) /dev/ufs/usr on /usr (ufs, NFS exported, local, soft-updates) arc1 on /zfs/arc1 (zfs, local, nfsv4acls) arc1/home on /home (zfs, local, nfsv4acls) arc1/Shared on /usr/archive/Shared (zfs, local, nfsv4acls) arc1/Private on /usr/archive/Private (zfs, local, nfsv4acls) root@obelix:~ # cat /etc/rc.conf | grep nfs nfs_server_enable="YES" nfsuserd_enable="YES" The handbook did not say I needed anything more than those. > You can quickly check that sharenfs=on via mount: > root@terpsichore> mount | grep NFS > system/export on /export (zfs, NFS exported, local, nfsv4acls) ^^^^^^^^^^^^ As you can see, this is always missing in my lines. Please also see my other post with the reference to the zfs manpage which states that nfs exports may also be managed via the /etc/exports file. Best regards, Chris From owner-freebsd-fs@FreeBSD.ORG Sat Feb 21 17:40:08 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93B356CE for ; Sat, 21 Feb 2015 17:40:08 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CA7FF9F for ; Sat, 21 Feb 2015 17:40:07 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YPE28-0006Ae-5k for freebsd-fs@freebsd.org; Sat, 21 Feb 2015 18:40:04 +0100 Received: from p5b02295d.dip0.t-ipconnect.de ([91.2.41.93]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Feb 2015 18:40:04 +0100 Received: from christian.baer by p5b02295d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Feb 2015 18:40:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Christian Baer Subject: Re: The magic of ZFS and NFS (2nd try) Date: Sat, 21 Feb 2015 18:36:16 +0100 Lines: 39 Message-ID: <12103095.viZFqgegqA@falbala.rz1.convenimus.net> References: <4257601.p3oiXZFr4n@falbala.rz1.convenimus.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p5b02295d.dip0.t-ipconnect.de User-Agent: KNode/4.14.2 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 17:40:08 -0000 Rainer Duffner wrote: > You must use the syntax of exports(5) also with zfs set sharenfs= > AFAIK, you shouldn’t use /etc/exports to do zfs exports but the above > command But why shouldn't I use /etc/exports? I have read people writing this (don't use /etc/exports) in forums when searching for answers, however the current manpage for zfs says this: sharenfs=on | off | opts Controls whether the file system is shared via NFS, and what options are used. A file system with a sharenfs property of off is managed the traditional way via exports(5). Otherwise, the file system is automatically shared and unshared with the "zfs share" and "zfs unshare" commands. If the property is set to on no NFS export options are used. Otherwise, NFS export options are equivalent to the con- tents of this property. The export options may be comma-separated. See exports(5) for a list of valid options. To me this looks like I can choose whether I want to use the exports file or if I wish to set the sharenfs flag. I don't really *that* much, although I don't really think this is something that a file system should decide, but should be set from the NFS server. > If your hosts you export to are in your nfs-server’s /etc/hosts, you will > need to use the names they resolve to also in the exports-statement. > (Though that might be wrong - it was the case with Solaris, though). I used IPs. See other post. > uids/gids should match, too, of course. They do. There aren't so many users so it's not too hard to keep up with that. :-) But I just checked again to make sure. Regards, Chris From owner-freebsd-fs@FreeBSD.ORG Sat Feb 21 18:23:08 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A984A96 for ; Sat, 21 Feb 2015 18:23:08 +0000 (UTC) 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 Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E79D266C for ; Sat, 21 Feb 2015 18:23:07 +0000 (UTC) X-ASG-Debug-ID: 1424542986-08ca043650aa850001-3nHGF7 Received: from mail.iXsystems.com ([10.2.55.1]) by barracuda.ixsystems.com with ESMTP id Ecxx0xj3Og621DGe (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 21 Feb 2015 10:23:06 -0800 (PST) X-Barracuda-Envelope-From: jkh@ixsystems.com X-Barracuda-RBL-Trusted-Forwarder: 10.2.55.1 X-ASG-Whitelist: Client Received: from [10.8.0.18] (unknown [10.8.0.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 00DAB8DF27; Sat, 21 Feb 2015 10:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1424542986; bh=Ghs01Gt9OSzGDspET4z1Msg9yStp/UnAYv7g16Krth0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=U3wLbbJ5llxxTBPXELe16hWGQKyPS1xAT/2Yj/04V9wOYcFnkH4O0A0yXHgr+AKbn hWQpdKscnlKK0GTgnbf4EkwYmIBBZgzvhDw+d9eMnF8vKikGPArpWO2Wj+z8vIe6sI D7FHLyfcgKqbjmmaYMgcd0ZowXfKzKQd6VxdNgwQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2081\)) Subject: Re: The magic of ZFS and NFS (2nd try) From: Jordan Hubbard X-ASG-Orig-Subj: Re: The magic of ZFS and NFS (2nd try) In-Reply-To: <12103095.viZFqgegqA@falbala.rz1.convenimus.net> Date: Sat, 21 Feb 2015 10:23:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4257601.p3oiXZFr4n@falbala.rz1.convenimus.net> <12103095.viZFqgegqA@falbala.rz1.convenimus.net> To: Christian Baer X-Mailer: Apple Mail (2.2081) X-Barracuda-Connect: UNKNOWN[10.2.55.1] X-Barracuda-Start-Time: 1424542986 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 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 18:23:08 -0000 > On Feb 21, 2015, at 9:36 AM, Christian Baer = wrote: >=20 > But why shouldn't I use /etc/exports? I have read people writing this = (don't=20 > use /etc/exports) in forums when searching for answers, however the = current=20 > manpage for zfs says this: FreeNAS has more experience with sharing things from ZFS than anyone = else in the BSD community (that=E2=80=99s not hyperbole, it=E2=80=99s = simply fact). We don=E2=80=99t use any of the zfs sharing flags. Those = were intended more for Solaris (sharesmb, for example - FreeBSD lets you = do that, but what does it *mean* when you don=E2=80=99t have a native = CIFS service?). FreeBSD has never integrated ZFS=E2=80=99s notion of = sharing or, for that matter, a number of other things like drive hot = sparing and automatic replacement, and you=E2=80=99re seeing the results = of ZFS=E2=80=99s solaris roots still not lining up 100% with their new = FreeBSD home. That=E2=80=99s all. I would simplify things, just as FreeNAS has (for good reasons), and = simply have ZFS be =E2=80=9Ca filesystem=E2=80=9D from FreeBSD=E2=80=99s = perspective and share it just as you would UFS. - Jordan From owner-freebsd-fs@FreeBSD.ORG Sat Feb 21 18:50:59 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE05DFA9 for ; Sat, 21 Feb 2015 18:50:59 +0000 (UTC) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (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 8FE25960 for ; Sat, 21 Feb 2015 18:50:59 +0000 (UTC) Received: by quine.pinyon.org (Postfix, from userid 122) id BEA15160254; Sat, 21 Feb 2015 11:50:57 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 3B7491600FA for ; Sat, 21 Feb 2015 11:50:55 -0700 (MST) Message-ID: <54E8D38F.9090608@pinyon.org> Date: Sat, 21 Feb 2015 11:50:55 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: The magic of ZFS and NFS (2nd try) References: <4257601.p3oiXZFr4n@falbala.rz1.convenimus.net> <12103095.viZFqgegqA@falbala.rz1.convenimus.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 18:50:59 -0000 On 02/21/15 11:23, Jordan Hubbard wrote: > >> On Feb 21, 2015, at 9:36 AM, Christian Baer >> wrote: >> >> But why shouldn't I use /etc/exports? I have read people writing >> this (don't use /etc/exports) in forums when searching for answers, >> however the current manpage for zfs says this: > > FreeNAS has more experience with sharing things from ZFS than anyone > else in the BSD community (that’s not hyperbole, it’s simply > fact). We don’t use any of the zfs sharing flags. Those were > intended more for Solaris (sharesmb, for example - FreeBSD lets you > do that, but what does it *mean* when you don’t have a native CIFS > service?). FreeBSD has never integrated ZFS’s notion of sharing > or, for that matter, a number of other things like drive hot sparing > and automatic replacement, and you’re seeing the results of ZFS’s > solaris roots still not lining up 100% with their new FreeBSD home. > That’s all. > > I would simplify things, just as FreeNAS has (for good reasons), and > simply have ZFS be “a filesystem” from FreeBSD’s perspective > and share it just as you would UFS. When I was working out my own mounts, it seemed that sharenfs=on was required to make them work, but I just checked and indeed I can mount a zfs file system over NFS4.1 without it. So I would definitely agree about not complicating things. Having both sharenfs and sharesmb *seem* to work does complicate figuring out how to make NFS work if you don't already know this, though. Back to Christian's problem, I don't see nfsv4_server_enable="YES" in your rc.conf lines. I have it in mine, and NFSv4 works. See man(4) nfsv4. You might have a look at /var/log/messages after restarting nfsd. Russell > > - Jordan > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, > send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Sat Feb 21 19:08:45 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19CD6372 for ; Sat, 21 Feb 2015 19:08:45 +0000 (UTC) Received: from mail.ultra-secure.de (mail.ultra-secure.de [88.198.178.88]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 74FECA6F for ; Sat, 21 Feb 2015 19:08:43 +0000 (UTC) Received: (qmail 41394 invoked by uid 89); 21 Feb 2015 19:08:41 -0000 Received: from unknown (HELO ?192.168.1.200?) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 21 Feb 2015 19:08:41 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: The magic of ZFS and NFS (2nd try) From: Rainer Duffner In-Reply-To: Date: Sat, 21 Feb 2015 20:08:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4257601.p3oiXZFr4n@falbala.rz1.convenimus.net> <12103095.viZFqgegqA@falbala.rz1.convenimus.net> To: Jordan Hubbard X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-fs@freebsd.org, Christian Baer X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 19:08:45 -0000 > Am 21.02.2015 um 19:23 schrieb Jordan Hubbard : >=20 >=20 >> On Feb 21, 2015, at 9:36 AM, Christian Baer = wrote: >>=20 >> But why shouldn't I use /etc/exports? I have read people writing this = (don't=20 >> use /etc/exports) in forums when searching for answers, however the = current=20 >> manpage for zfs says this: >=20 > FreeNAS has more experience with sharing things from ZFS than anyone = else in the BSD community (that=E2=80=99s not hyperbole, it=E2=80=99s = simply fact). We don=E2=80=99t use any of the zfs sharing flags. Those = were intended more for Solaris (sharesmb, for example - FreeBSD lets you = do that, but what does it *mean* when you don=E2=80=99t have a native = CIFS service?). FreeBSD has never integrated ZFS=E2=80=99s notion of = sharing or, for that matter, a number of other things like drive hot = sparing and automatic replacement, and you=E2=80=99re seeing the results = of ZFS=E2=80=99s solaris roots still not lining up 100% with their new = FreeBSD home. That=E2=80=99s all. >=20 > I would simplify things, just as FreeNAS has (for good reasons), and = simply have ZFS be =E2=80=9Ca filesystem=E2=80=9D from FreeBSD=E2=80=99s = perspective and share it just as you would UFS. Interesting. I admit I don=E2=80=99t use NFS v4. Is it much faster than NFS v3 these days? But I=E2=80=99ve always added the line from exports(5) into the sharenfs = property like zfs get sharenfs datapool/nfs/ds3-documents NAME PROPERTY VALUE = SOURCE datapool/nfs/ds3-documents sharenfs -maproot=3D1003 -network = 10.10.10.0 -mask 255.255.255.0 inherited from datapool/nfs These lines get written into /etc/zfs/exports I like it that way because if a filesystem is destroyed, I don=E2=80=99t = have to remember removing it from /etc/exports. I also admit I=E2=80=99m heavily influenced by Solaris on this = particular setting=E2=80=A6 From owner-freebsd-fs@FreeBSD.ORG Sat Feb 21 21:07:18 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BCE0EC0 for ; Sat, 21 Feb 2015 21:07:18 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.redhat.com", Issuer "DigiCert SHA2 Extended Validation Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01CB282B for ; Sat, 21 Feb 2015 21:07:17 +0000 (UTC) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1LL7BdU009367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 21 Feb 2015 16:07:11 -0500 Received: from [10.36.6.102] (vpn1-6-102.ams2.redhat.com [10.36.6.102]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1LL77rR019717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Feb 2015 16:07:09 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: The magic of ZFS and NFS (2nd try) From: Justin Clift In-Reply-To: Date: Sat, 21 Feb 2015 21:07:08 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0FBD2FE2-6B50-4CA5-92E7-81D02AF655C2@gluster.org> References: <4257601.p3oiXZFr4n@falbala.rz1.convenimus.net> <12103095.viZFqgegqA@falbala.rz1.convenimus.net> To: Jordan Hubbard X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Cc: freebsd-fs@freebsd.org, Christian Baer X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 21:07:18 -0000 On 21 Feb 2015, at 18:23, Jordan Hubbard wrote: >> On Feb 21, 2015, at 9:36 AM, Christian Baer = wrote: >>=20 >> But why shouldn't I use /etc/exports? I have read people writing this = (don't=20 >> use /etc/exports) in forums when searching for answers, however the = current=20 >> manpage for zfs says this: >=20 > FreeNAS has more experience with sharing things from ZFS than anyone = else in the BSD community (that=92s not hyperbole, it=92s simply fact). = We don=92t use any of the zfs sharing flags. Those were intended more = for Solaris (sharesmb, for example - FreeBSD lets you do that, but what = does it *mean* when you don=92t have a native CIFS service?). FreeBSD = has never integrated ZFS=92s notion of sharing or, for that matter, a = number of other things like drive hot sparing and automatic replacement, = and you=92re seeing the results of ZFS=92s solaris roots still not = lining up 100% with their new FreeBSD home. That=92s all. >=20 > I would simplify things, just as FreeNAS has (for good reasons), and = simply have ZFS be =93a filesystem=94 from FreeBSD=92s perspective and = share it just as you would UFS. As a possible alternative thought, if anyone has patches to make the above work with FreeBSD, they'd probably be considered. Just saying. ;) Regards and best wishes, Justin Clift -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift