From owner-freebsd-fs@FreeBSD.ORG Sun Apr 19 12:29:28 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 3E8F98A7 for ; Sun, 19 Apr 2015 12:29:28 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 097FA345 for ; Sun, 19 Apr 2015 12:29:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CmBAAtnzNV/95baINchD+DEsgiglyBXBEBAQEBAQEBfYQiKFYzAgINGQJfiD60I5QNAQEBBwEBAQEBHYEhjk8XNIJvgUUFnGuQNYNOIoIFHYFtIoF1gQABAQE X-IronPort-AV: E=Sophos;i="5.11,603,1422939600"; d="scan'208";a="206439225" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 19 Apr 2015 08:29:26 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 70E26B3F67; Sun, 19 Apr 2015 08:29:26 -0400 (EDT) Date: Sun, 19 Apr 2015 08:29:26 -0400 (EDT) From: Rick Macklem To: J David Cc: FreeBSD Filesystems Message-ID: <1287096585.21725198.1429446566451.JavaMail.root@uoguelph.ca> Subject: FreeBSD 10.1 can't "make -j5 buildworld" over NFS? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 12:29:28 -0000 J David wrote: > On identical hardware, against the exact same NFS server, FreeBSD 9.3 > can do a parallel buildworld, but FreeBSD 10.1 dies in cleandir with a > bunch of "stale NFS file handle" errors. > > The mount options are the same on both clients: > > 192.168.20.161:/data/software/freebsd/releng-9.3/src /usr/src nfs > rw,tcp,nfsv3,noauto 0 0 > 192.168.20.161:/data/software/freebsd/releng-9.3/amd64/obj /usr/obj > nfs rw,tcp,nfsv3,noauto 0 0 > > > 192.168.20.161:/data/software/freebsd/releng-10.1/src /usr/src nfs > rw,tcp,nfsv3,noauto 0 0 > 192.168.20.161:/data/software/freebsd/releng-10.1/amd64/obj /usr/obj > nfs rw,tcp,nfsv3,noauto 0 0 [rest clipped for brevity] I checked and I was incorrect w.r.t. "make" changing. One thing you could try (although you said you weren't going to do anything on your last post) is disabling lookup using shared vnode locks. # sysctl vfs.lookup_shared=0 and see if that stops it from failing with ESTALE. Here's a comment from the NFS client code nfs_remove() (been there for quite a while): 1674 /* 1675 * Purge the name cache so that the chance of a lookup for 1676 * the name succeeding while the remove is in progress is 1677 * minimized. Without node locking it can still happen, such 1678 * that an I/O op returns ESTALE, but since you get this if 1679 * another host removes the file.. 1680 */ I don`t believe I wrote this comment, but my understanding is that a second thread may succeed in looking up the file (hit on the name cache) while the remove is in progress and then attempt the remove again. Disabling shared vnode locking (forcing the lookup that preceeds the remove to acquire an exclusive lock on the directory might avoid the race. My comment w.r.t. NFS not being POSIX compliant wasn`t meant to say that this problem wasn`t fixable or shouldn`t be fixed, it was meant to imply that working on a POSIX file system doesn`t imply working over NFS. Since FreeBSD9.3 also has shared vnode locking enabled for lookups (unless you disabled them), I don`t know why 10.1 would break and 9.3 doesn`t. rick From owner-freebsd-fs@FreeBSD.ORG Sun Apr 19 12:57: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 AEF3890 for ; Sun, 19 Apr 2015 12:57: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 98E7A845 for ; Sun, 19 Apr 2015 12:57:57 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3JCvvpc063912 for ; Sun, 19 Apr 2015 12:57:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 141950] [unionfs] [lor] ufs/unionfs/ufs Lock order reversal Date: Sun, 19 Apr 2015 12:57:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dbn@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 12:57:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=141950 David Naylor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |Overcome By Events --- Comment #8 from David Naylor --- Timeout -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sun Apr 19 15:56:17 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 D10F7FF6 for ; Sun, 19 Apr 2015 15:56:17 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (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 5B4A9B5E for ; Sun, 19 Apr 2015 15:56:17 +0000 (UTC) Received: by lbcga7 with SMTP id ga7so114289123lbc.1 for ; Sun, 19 Apr 2015 08:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ovlBGbQHEP68I/ll3Leh7nh8SnNtu+cWlFHSEh86rIg=; b=prcC+mjGgVxaIYdGDdGISe6u8i+n2EW/AwqHN3d+n4Xt7f9KK2zt8AF3C0VaVHRSuG 1bLO0/LEuD5HYHm8gdRJUl5oCUVz3v7g638O1TlFjdoI7ff+vRUKxdMLy93CJypYAftk leWZdw2DiilW3xexDQS99PBj6Zxrwup6IsPRPwcU6zgBwqjYIWERpNs9dldgUHJF7NnE QUoIHgry4R5peqa6+dLgZdnK6o5fnx8QYdCcK9i8InPthK9o4IREu0IoMWDUjzqXzO/+ vR6u+lcAC2BUML5o6qseiF6o+Sj1P63D5KNwQmgGUKfRFXmOQUVeh70S5FrkvIW5rK2g h8jw== MIME-Version: 1.0 X-Received: by 10.152.203.134 with SMTP id kq6mr12273127lac.110.1429458974389; Sun, 19 Apr 2015 08:56:14 -0700 (PDT) Received: by 10.114.18.137 with HTTP; Sun, 19 Apr 2015 08:56:14 -0700 (PDT) Date: Sun, 19 Apr 2015 08:56:14 -0700 Message-ID: Subject: Resize geli provider (md) From: javocado To: FreeBSD Filesystems Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 15:56:17 -0000 I have a md-backed geli mount which I created as follows: dd if=/dev/zero of=geli.img bs=1m count=102400 mdconfig -f geli.img -u 123 geli init /dev/md123 (blank pass) geli attach /dev/md123 newfs /dev/md123.eli mkdir encrypted mount /dev/md123.eli encrypted And I wish to expand it's size. The method I've been using is to create new larger device and copy data over, but I'm hoping there's a better way to expand in place (without the loss of the existing data). Any advice? Thanks! From owner-freebsd-fs@FreeBSD.ORG Sun Apr 19 16:15: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 647DC3E0 for ; Sun, 19 Apr 2015 16:15:45 +0000 (UTC) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) (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 24BE0D24 for ; Sun, 19 Apr 2015 16:15:44 +0000 (UTC) Received: from [84.44.154.227] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1Yjrsd-0006UC-Va; Sun, 19 Apr 2015 18:15:36 +0200 Date: Sun, 19 Apr 2015 18:15:37 +0200 From: Fabian Keil To: javocado Cc: FreeBSD Filesystems Subject: Re: Resize geli provider (md) Message-ID: <29d12e6f.643fd081@fabiankeil.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/qM.Frm4x4ElpJ2IkGLLdFZ+"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 16:15:45 -0000 --Sig_/qM.Frm4x4ElpJ2IkGLLdFZ+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable javocado wrote: > I have a md-backed geli mount which I created as follows: >=20 > dd if=3D/dev/zero of=3Dgeli.img bs=3D1m count=3D102400 > mdconfig -f geli.img -u 123 > geli init /dev/md123 (blank pass) > geli attach /dev/md123 > newfs /dev/md123.eli > mkdir encrypted > mount /dev/md123.eli encrypted >=20 > And I wish to expand it's size. The method I've been using is to create n= ew > larger device and copy data over, but I'm hoping there's a better way to > expand in place (without the loss of the existing data). Any advice? Increase the size of geli.img (for example with truncate -s +...), resize the geli provider with 'geli resize', and finally grow the file system with growfs. For details see the man pages. Fabian --Sig_/qM.Frm4x4ElpJ2IkGLLdFZ+ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUz1KYACgkQBYqIVf93VJ3HkgCgwJETDJGOvvQNhM+0S0uNNMK4 MewAoJIvIC00UXyKYy91R8ovhY5j9sZ1 =HBOc -----END PGP SIGNATURE----- --Sig_/qM.Frm4x4ElpJ2IkGLLdFZ+-- From owner-freebsd-fs@FreeBSD.ORG Sun Apr 19 21:00: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 AB55A934 for ; Sun, 19 Apr 2015 21:00:11 +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 847D2D19 for ; Sun, 19 Apr 2015 21:00:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3JL0BCQ060611 for ; Sun, 19 Apr 2015 21:00:11 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201504192100.t3JL0BCQ060611@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, 19 Apr 2015 21:00:11 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 21:00:11 -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 Apr 19 23:57: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 3B4215B5 for ; Sun, 19 Apr 2015 23:57:30 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id E751FFED for ; Sun, 19 Apr 2015 23:57:29 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CoBABYQDRV/95baINbg15hgxLEe4YHAoFeEQEBAQEBAQF9hCcjBH8XGQIERw4GiD6kV49VlAgBAQEBAQUBAQEBAQEBFwSPWAsGAQIbO4JogUUFkxuCDJtHIoICAx2BbSKBNAgXIoEAAQEB X-IronPort-AV: E=Sophos;i="5.11,605,1422939600"; d="scan'208";a="206493904" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 19 Apr 2015 19:57:22 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B60FBB3FC4 for ; Sun, 19 Apr 2015 19:57:22 -0400 (EDT) Date: Sun, 19 Apr 2015 19:57:22 -0400 (EDT) From: Rick Macklem To: FreeBSD Filesystems Message-ID: <1552767461.21885039.1429487842728.JavaMail.root@uoguelph.ca> In-Reply-To: <963641485.21885012.1429487839649.JavaMail.root@uoguelph.ca> Subject: Patch that defines MAXBCACHEBUF separate from MAXBSIZE for review MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_21885037_470978965.1429487842726" X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 23:57:30 -0000 ------=_Part_21885037_470978965.1429487842726 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, MAXBSIZE is both the maximum UFS block size and the maximum size of a buffer cache block. This patch defines MAXBCACHEBUF as a separate constant that is the maximum size of a buffer cache block. This allows it to be set on a per-architecture basis and, therefore, can be made larger than MAXBSIZE so that the NFS client can do larger reads/writes, for 64bit architectures. The patch is here for review: https://reviews.freebsd.org/D2330 and is also attached. Since I've never used Phabricator, I suspect it's messed up, but just email if you want to review this or comment and can't do it in phabricator. rick ------=_Part_21885037_470978965.1429487842726 Content-Type: text/x-patch; name=buftune2.patch Content-Disposition: attachment; filename=buftune2.patch Content-Transfer-Encoding: base64 LS0tIGtlcm4vdmZzX2Jpby5jLnNhdmJ1ZgkyMDE1LTAzLTMwIDIxOjI0OjM5LjAwMDAwMDAwMCAt MDQwMAorKysga2Vybi92ZnNfYmlvLmMJMjAxNS0wNC0xOCAxNzo1NToxNi4wMDAwMDAwMDAgLTA0 MDAKQEAgLTgwNSw2ICs4MDUsNyBAQCBidWZpbml0KHZvaWQpCiAJc3RydWN0IGJ1ZiAqYnA7CiAJ aW50IGk7CiAKKwlDVEFTU0VSVChNQVhCQ0FDSEVCVUYgPj0gTUFYQlNJWkUpOwogCW10eF9pbml0 KCZicWNsZWFuLCAiYnVmcSBjbGVhbiBsb2NrIiwgTlVMTCwgTVRYX0RFRik7CiAJbXR4X2luaXQo JmJxZGlydHksICJidWZxIGRpcnR5IGxvY2siLCBOVUxMLCBNVFhfREVGKTsKIAltdHhfaW5pdCgm cmJyZXFsb2NrLCAicnVubmluZ2J1ZnNwYWNlIGxvY2siLCBOVUxMLCBNVFhfREVGKTsKQEAgLTg0 Niw4ICs4NDcsOCBAQCBidWZpbml0KHZvaWQpCiAJICogYnkgdGhlIHN5c3RlbS4KIAkgKi8KIAlt YXhidWZzcGFjZSA9IChsb25nKW5idWYgKiBCS1ZBU0laRTsKLQloaWJ1ZnNwYWNlID0gbG1heCgz ICogbWF4YnVmc3BhY2UgLyA0LCBtYXhidWZzcGFjZSAtIE1BWEJTSVpFICogMTApOwotCWxvYnVm c3BhY2UgPSBoaWJ1ZnNwYWNlIC0gTUFYQlNJWkU7CisJaGlidWZzcGFjZSA9IGxtYXgoMyAqIG1h eGJ1ZnNwYWNlIC8gNCwgbWF4YnVmc3BhY2UgLSBNQVhCQ0FDSEVCVUYgKiAxMCk7CisJbG9idWZz cGFjZSA9IGhpYnVmc3BhY2UgLSBNQVhCQ0FDSEVCVUY7CiAKIAkvKgogCSAqIE5vdGU6IFRoZSAx NiBNaUIgdXBwZXIgbGltaXQgZm9yIGhpcnVubmluZ3NwYWNlIHdhcyBjaG9zZW4KQEAgLTg1Nyw5 ICs4NTgsOSBAQCBidWZpbml0KHZvaWQpCiAJICogVGhlIGxvd2VyIDEgTWlCIGxpbWl0IGlzIHRo ZSBoaXN0b3JpY2FsIHVwcGVyIGxpbWl0IGZvcgogCSAqIGhpcnVubmluZ3NwYWNlLgogCSAqLwot CWhpcnVubmluZ3NwYWNlID0gbG1heChsbWluKHJvdW5kdXAoaGlidWZzcGFjZSAvIDY0LCBNQVhC U0laRSksCisJaGlydW5uaW5nc3BhY2UgPSBsbWF4KGxtaW4ocm91bmR1cChoaWJ1ZnNwYWNlIC8g NjQsIE1BWEJDQUNIRUJVRiksCiAJICAgIDE2ICogMTAyNCAqIDEwMjQpLCAxMDI0ICogMTAyNCk7 Ci0JbG9ydW5uaW5nc3BhY2UgPSByb3VuZHVwKChoaXJ1bm5pbmdzcGFjZSAqIDIpIC8gMywgTUFY QlNJWkUpOworCWxvcnVubmluZ3NwYWNlID0gcm91bmR1cCgoaGlydW5uaW5nc3BhY2UgKiAyKSAv IDMsIE1BWEJDQUNIRUJVRik7CiAKIC8qCiAgKiBMaW1pdCB0aGUgYW1vdW50IG9mIG1hbGxvYyBt ZW1vcnkgc2luY2UgaXQgaXMgd2lyZWQgcGVybWFuZW50bHkgaW50bwpAQCAtMzA3Myw4ICszMDc0 LDkgQEAgZ2V0YmxrKHN0cnVjdCB2bm9kZSAqdnAsIGRhZGRyX3QgYmxrbm8sIAogCUtBU1NFUlQo KGZsYWdzICYgKEdCX1VOTUFQUEVEIHwgR0JfS1ZBQUxMT0MpKSAhPSBHQl9LVkFBTExPQywKIAkg ICAgKCJHQl9LVkFBTExPQyBvbmx5IG1ha2VzIHNlbnNlIHdpdGggR0JfVU5NQVBQRUQiKSk7CiAJ QVNTRVJUX1ZPUF9MT0NLRUQodnAsICJnZXRibGsiKTsKLQlpZiAoc2l6ZSA+IE1BWEJTSVpFKQot CQlwYW5pYygiZ2V0YmxrOiBzaXplKCVkKSA+IE1BWEJTSVpFKCVkKVxuIiwgc2l6ZSwgTUFYQlNJ WkUpOworCWlmIChzaXplID4gTUFYQkNBQ0hFQlVGKQorCQlwYW5pYygiZ2V0YmxrOiBzaXplKCVk KSA+IE1BWEJDQUNIRUJVRiglZClcbiIsIHNpemUsCisJCSAgICBNQVhCQ0FDSEVCVUYpOwogCWlm ICghdW5tYXBwZWRfYnVmX2FsbG93ZWQpCiAJCWZsYWdzICY9IH4oR0JfVU5NQVBQRUQgfCBHQl9L VkFBTExPQyk7CiAKLS0tIGZzL25mc2NsaWVudC9uZnNfY2x2ZnNvcHMuYy5zYXZidWYJMjAxNS0w NC0xNyAxNzoyNTowMS4wMDAwMDAwMDAgLTA0MDAKKysrIGZzL25mc2NsaWVudC9uZnNfY2x2ZnNv cHMuYwkyMDE1LTA0LTE4IDE4OjAyOjI1LjAwMDAwMDAwMCAtMDQwMApAQCAtMjAxLDE2ICsyMDEs MTYgQEAgbmV3bmZzX2lvc2l6ZShzdHJ1Y3QgbmZzbW91bnQgKm5tcCkKIAl9CiAJaWYgKG5tcC0+ bm1fcnNpemUgPiBtYXhpbyB8fCBubXAtPm5tX3JzaXplID09IDApCiAJCW5tcC0+bm1fcnNpemUg PSBtYXhpbzsKLQlpZiAobm1wLT5ubV9yc2l6ZSA+IE1BWEJTSVpFKQotCQlubXAtPm5tX3JzaXpl ID0gTUFYQlNJWkU7CisJaWYgKG5tcC0+bm1fcnNpemUgPiBORlNfTUFYQlNJWkUpCisJCW5tcC0+ bm1fcnNpemUgPSBORlNfTUFYQlNJWkU7CiAJaWYgKG5tcC0+bm1fcmVhZGRpcnNpemUgPiBtYXhp byB8fCBubXAtPm5tX3JlYWRkaXJzaXplID09IDApCiAJCW5tcC0+bm1fcmVhZGRpcnNpemUgPSBt YXhpbzsKIAlpZiAobm1wLT5ubV9yZWFkZGlyc2l6ZSA+IG5tcC0+bm1fcnNpemUpCiAJCW5tcC0+ bm1fcmVhZGRpcnNpemUgPSBubXAtPm5tX3JzaXplOwogCWlmIChubXAtPm5tX3dzaXplID4gbWF4 aW8gfHwgbm1wLT5ubV93c2l6ZSA9PSAwKQogCQlubXAtPm5tX3dzaXplID0gbWF4aW87Ci0JaWYg KG5tcC0+bm1fd3NpemUgPiBNQVhCU0laRSkKLQkJbm1wLT5ubV93c2l6ZSA9IE1BWEJTSVpFOwor CWlmIChubXAtPm5tX3dzaXplID4gTkZTX01BWEJTSVpFKQorCQlubXAtPm5tX3dzaXplID0gTkZT X01BWEJTSVpFOwogCiAJLyoKIAkgKiBDYWxjdWxhdGUgdGhlIHNpemUgdXNlZCBmb3IgaW8gYnVm ZmVycy4gIFVzZSB0aGUgbGFyZ2VyCi0tLSBmcy9uZnMvbmZzcG9ydC5oLnNhdmJ1ZgkyMDE1LTAz LTMwIDIxOjUxOjA1LjAwMDAwMDAwMCAtMDQwMAorKysgZnMvbmZzL25mc3BvcnQuaAkyMDE1LTAz LTMwIDIxOjUxOjM4LjAwMDAwMDAwMCAtMDQwMApAQCAtOTUyLDcgKzk1Miw3IEBAIHN0cnVjdCBu ZnNyZXEgewogfTsKIAogI2lmbmRlZiBORlNfTUFYQlNJWkUKLSNkZWZpbmUJTkZTX01BWEJTSVpF CU1BWEJTSVpFCisjZGVmaW5lCU5GU19NQVhCU0laRQlNQVhCQ0FDSEVCVUYKICNlbmRpZgogCiAv KgotLS0gc3lzL3BhcmFtLmguc2F2YnVmCTIwMTUtMDMtMjcgMjI6MTA6MTQuMDAwMDAwMDAwIC0w NDAwCisrKyBzeXMvcGFyYW0uaAkyMDE1LTA0LTE5IDA4OjUxOjIyLjAwMDAwMDAwMCAtMDQwMApA QCAtMjMzLDEwICsyMzMsMTkgQEAKICAqCQlhbmQgbWF5IGJlIG1hZGUgc21hbGxlciBhdCB0aGUg cmlzayBvZiBub3QgYmVpbmcgYWJsZSB0byB1c2UKICAqCQlmaWxlc3lzdGVtcyB3aGljaCByZXF1 aXJlIGEgYmxvY2sgc2l6ZSBleGNlZWRpbmcgTUFYQlNJWkUuCiAgKgorICogTUFYQkNBQ0hFQlVG IC0gTWF4aW11bSBzaXplIG9mIGEgYnVmZmVyIGluIHRoZSBidWZmZXIgY2FjaGUuICBUaGlzIG11 c3QKKyAqCQliZSA+PSBNQVhCU0laRSBhbmQgY2FuIGJlIHNldCBkaWZmZXJlbnRseSBmb3IgZGlm ZmVyZW50CisgKgkJYXJjaGl0ZWN0dXJlcyBieSBkZWZpbmluZyBpdCBpbiA8bWFjaGluZS9wYXJh bS5oPi4KKyAqCQlNYWtpbmcgdGhpcyBsYXJnZXIgYWxsb3dzIE5GUyB0byBkbyBsYXJnZXIgcmVh ZHMvd3JpdGVzLgorICoKICAqIEJLVkFTSVpFIC0JTm9taW5hbCBidWZmZXIgc3BhY2UgcGVyIGJ1 ZmZlciwgaW4gYnl0ZXMuICBCS1ZBU0laRSBpcyB0aGUKICAqCQltaW5pbXVtIEtWTSBtZW1vcnkg cmVzZXJ2YXRpb24gdGhlIGtlcm5lbCBpcyB3aWxsaW5nIHRvIG1ha2UuCiAgKgkJRmlsZXN5c3Rl bXMgY2FuIG9mIGNvdXJzZSByZXF1ZXN0IHNtYWxsZXIgY2h1bmtzLiAgQWN0dWFsIAogICoJCWJh Y2tpbmcgbWVtb3J5IHVzZXMgYSBjaHVuayBzaXplIG9mIGEgcGFnZSAoUEFHRV9TSVpFKS4KKyAq CQlUaGUgZGVmYXVsdCB2YWx1ZSBoZXJlIGNhbiBiZSBvdmVycmlkZGVuIG9uIGEgcGVyLWFyY2hp dGVjdHVyZQorICoJCWJhc2lzIGJ5IGRlZmluaW5nIGl0IGluIDxtYWNoaW5lL3BhcmFtLmg+LiAg VGhpcyBzaG91bGQKKyAqCQlwcm9iYWJseSBiZSBkb25lIHRvIGluY3JlYXNlIGl0cyB2YWx1ZSwg d2hlbiBNQVhCQ0FDSEVCVUYgaXMKKyAqCQlkZWZpbmVkIGFzIGEgbGFyZ2VyIHZhbHVlIGluIDxt YWNoaW5lL3BhcmFtLmg+LgogICoKICAqCQlJZiB5b3UgbWFrZSBCS1ZBU0laRSB0b28gc21hbGwg eW91IHJpc2sgc2VyaW91c2x5IGZyYWdtZW50aW5nCiAgKgkJdGhlIGJ1ZmZlciBLVk0gbWFwIHdo aWNoIG1heSBzbG93IHRoaW5ncyBkb3duIGEgYml0LiAgSWYgeW91CkBAIC0yNDgsNyArMjU3LDEy IEBACiAgKgkJbm9ybWFsIFVGUyBmaWxlc3lzdGVtLgogICovCiAjZGVmaW5lIE1BWEJTSVpFCTY1 NTM2CS8qIG11c3QgYmUgcG93ZXIgb2YgMiAqLworI2lmbmRlZglNQVhCQ0FDSEVCVUYKKyNkZWZp bmUJTUFYQkNBQ0hFQlVGCU1BWEJTSVpFIC8qIG11c3QgYmUgYSBwb3dlciBvZiAyID49IE1BWEJT SVpFICovCisjZW5kaWYKKyNpZm5kZWYJQktWQVNJWkUKICNkZWZpbmUgQktWQVNJWkUJMTYzODQJ LyogbXVzdCBiZSBwb3dlciBvZiAyICovCisjZW5kaWYKICNkZWZpbmUgQktWQU1BU0sJKEJLVkFT SVpFLTEpCiAKIC8qCg== ------=_Part_21885037_470978965.1429487842726-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 20 06:14: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 9ECB1E6C for ; Mon, 20 Apr 2015 06:14:11 +0000 (UTC) Received: from sum.zhabenwang.com (sum.zhabenwang.com [178.251.230.20]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2D6B58 for ; Mon, 20 Apr 2015 06:14:10 +0000 (UTC) To: freebsd-fs@freebsd.org Subject: about email marketing solutions Message-ID: <4ae45117d38a4d1babb09953c008fb6f@thermatru.com> Date: Mon, 20 Apr 2015 08:04:31 +0200 From: "Louis" Reply-To: bonnietongy@sina.com MIME-Version: 1.0 X-Mailer-LID: 9 X-Mailer-RecptId: 8812750 X-Mailer-SID: 359 X-Mailer-Sent-By: 1 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 06:14:11 -0000 Hi, You are receiving this email because we wish you to use our target email marketing service. We specialize in providing target email marketing services to a number of businesses all over the world! Email marketing is one of the best marketing strategies of all time and has helped many businesses globally achieve their goals, double their profits and increase their client base. We have worked on a number of projects and campaigns, all our packages are tailor made and designed according to your requirements. We wish to be your marketing partner, we can increase your business sales 2-5 times. If you would require more information please send us an email and we would be glad to discuss the project requirements with you soon. Looking forward to your positive response. Kind Regards Louis Marketing Specialist Email: wukelili@tom.com From owner-freebsd-fs@FreeBSD.ORG Mon Apr 20 09:09:42 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 34632178 for ; Mon, 20 Apr 2015 09:09:42 +0000 (UTC) Received: from EXCH2-1.slu.se (pop.slu.se [77.235.224.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "webmail.slu.se", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF8C18B for ; Mon, 20 Apr 2015 09:09:40 +0000 (UTC) Received: from Exch2-3.slu.se (77.235.224.123) by EXCH2-1.slu.se (77.235.224.121) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 20 Apr 2015 10:54:25 +0200 Received: from Exch2-3.slu.se ([fe80::817d:eadf:824e:cfed]) by Exch2-3.slu.se ([fe80::817d:eadf:824e:cfed%23]) with mapi id 15.00.0995.032; Mon, 20 Apr 2015 10:54:25 +0200 From: =?utf-8?B?S2FybGkgU2rDtmJlcmc=?= To: FreeBSD Filesystems Subject: BTX halted Thread-Topic: BTX halted Thread-Index: AQHQe0eZT2mAoX6cPEaajPuYm9wk8Q== Date: Mon, 20 Apr 2015 08:54:24 +0000 Message-ID: <1429520064.12915.56.camel@data-b104.adm.slu.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.235.228.32] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 09:09:42 -0000 SGV5IGFsbCENCg0KSSB3YXMganVzdCB1cGdyYWRpbmcgb25lIG9mIG91ciBzdG9yYWdlJ3MgdG8g MTAtU1RBQkxFIGFzIHBlciBCdWcNCjE5MTM0OFsqXSB3aGVuIHNvbWV0aGluZyBzdHJhbmdlIGhh cHBlbmVkIGFmdGVyIHdyaXRpbmcgbmV3IGJvb3QgY29kZQ0KYW5kIHJlYm9vdGluZzoNCg0KQlRY IGxvYWRlciAxLjAwICBCVFggdmVyc2lvbiBpcyAxLjAyDQpDb25zb2xlczogaW50ZXJuYWwgdmlk ZW8va2V5Ym9hcmQNCkJJT1MgZHJpdmUgQzogaXMgZGlzazgNCkJJT1MgZHJpdmUgRDogaXMgZGlz azkNCg0KaW50PTAwMDAwMDAwICBlcnI9MDAwMDAwMDAgIGVmbD0wMDAxMDI0NiAgZWlwPTAwMDM3 ZDM0DQplYXg9MDAwMDAwMDEgIGVieD0wMDAwMDAwMCAgZWN4PTAwMDAwMDAwICBlZHg9MDAwMDAw MDANCmVzaT0wMDAwMDAwMCAgZWRpPTAwMDAwMDAwICBlYnA9MDAwOGY2MDAgIGVzcD0wMDA4ZjU5 OA0KY3M9MDAyYiAgZHM9MDAzMyAgZXM9MDAzMyAgICBmcz0wMDMzICBncz0wMDMzICBzcz0wMDMz DQpjczplaXA9ZjcgMzUgZDAgZjQgMDMgMDAgODUgZjYtNzQgMDUgODkgM2UgODkgNWUgMDQgODkN CiAgICAgICBjMiBlOSBjYyAwMCAwMCAwMCA2NiBjNy00NSBlYSAwMCAwMCA4OSBkOCBjMSBlOA0K c3M6ZXNwPTAwIDAwIDIwIDAwIDAwIDAwIDAwIDAwLTAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwDQog ICAgICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAtMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDANCkJU WCBoYWx0ZWQNCg0KTmV2ZXIgaGFwcGVuZWQgdG8gbWUgYmVmb3JlLiBJIHRoZW4gYm9vdGVkIHdp dGggYSAxMC4xLVJFTEVBU0UgQ0QgYW5kDQp3cm90ZSBib290Y29kZSBmcm9tIHRoYXQsIHNhbWUg cHJvYmxlbS4gOS4zOyBzYW1lIHRoZXJlLi4uDQoNCkFueSBwb2ludGVycz8NCg0KL0sNCg0KWypd OiBodHRwczovL2J1Z3MuZnJlZWJzZC5vcmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTE5MTM0 OA0KDQo= From owner-freebsd-fs@FreeBSD.ORG Mon Apr 20 09:29:44 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 EB365520 for ; Mon, 20 Apr 2015 09:29:44 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id AEC96301 for ; Mon, 20 Apr 2015 09:29:44 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:d0f8:fbff:df57:1c18]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 2F70F11CB for ; Mon, 20 Apr 2015 12:29:42 +0300 (MSK) Date: Mon, 20 Apr 2015 12:29:39 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <710623939.20150420122931@serebryakov.spb.ru> To: freebsd-fs@freebsd.org Subject: ZFS: exclude one FS from recurive snapshot creation? Or some equivalent to "nodump" for dataset? MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="----------03114A07D0BE3FB03" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 09:29:45 -0000 ------------03114A07D0BE3FB03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hello Freebsd-fs, I have set of ZFS filesystems, one fielsystem per user like this: zroot/home/group1/user11 zroot/home/group1/user12 zroot/home/group1/user13 zroot/home/group2/user21 zroot/home/group2/user22 zroot/home/group3/user31 ... I want to create complete snapshots of "zroot/home" tree regularly (with zfSnap), but I have one "user" which holds a huge amount of easy-reconstructible data, which I don't wont to store in snapshots. Is it possible to exclude one dataset (filesystem) from "zfs snap -r"? I don't want to enumerate all but this filesystem in configuration file, as it is error-prone and requires editing configs each time user is created or removed. P.S. I start to understand how much I love "nodump" flag on UFS and it usage with "dump" command! Absence of such functionality for "zfs send" is really pity. --=20 Best regards, Lev mailto:lev@FreeBSD.org ------------03114A07D0BE3FB03 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJVNMcDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePsU4P/RnPIB2etN8VwTACLnS3WRep +hPGXNlWkEzUxlLTWGznwJZrK8P2b3idAC0r/06rnK9D++KH44h8auo5FUcpa34m TZ2YhNoyGngWLfeHue9MZB0vUM/ZV4BO38glmb04zylmFRKxvjUMFNL24iJbhoXQ RaWEwC0OQ5rMBbL1Qup7JmNmcqlOhRISvQYhbH8db2X3a3bGiNFQ/QMyxEza+e+X B+7rKoBYOzgYoAfdKx0vEBixys/EwiDe8P229S6cZt+hPCXHB5GiEV+u6FuY6gC5 EQqGRNurf8gshA13Kg52U9KY53PhwFjnhWiife8e1ZMk3xbVsC4lhEkSjOiZrJQ3 /Dto90ZcIuPA/2BkgRHLrnJlqt9ocIrnHVnUicSVK8/KNGC8DN4KW6KhX6XxXuiW IRoP8D9Wh6BaAoodScBjMpxsoJeLUrJRJ6V0TOv+INqvlQ/s9gVlZM5y2mRZ7Zhv kKP913tA9BOsPRGUa1GjSDYQDelpVme82LBc6hp9HW6zfrPMSa2ZXwXY42jTYKCU KnBP+exgrGIzmhQdtQUeYsHh8jN+b2wNK8WBOM/v3Cpeecl6tR0yTa/qm2GuGZG9 aq4GXMOUHuBriHSYuGFjTe7tmZTdrEHQNU2dl0DdVkPai6yW5Bei6Nd0RvzGst0g AZlKyCypWYhJexfUQjbs =o7J2 -----END PGP MESSAGE----- ------------03114A07D0BE3FB03-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 20 09:50:32 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 5DBFC902 for ; Mon, 20 Apr 2015 09:50:32 +0000 (UTC) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 EDB756D4 for ; Mon, 20 Apr 2015 09:50:31 +0000 (UTC) Received: by widdi4 with SMTP id di4so84623704wid.0 for ; Mon, 20 Apr 2015 02:50:24 -0700 (PDT) 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=v1N1niV4o/1r7ynpiCWPyH2w3CrvE/22s2B9U7aPqYs=; b=lMeeR4o1s1vjFElmI/uXAxTqAX0LHODOmM8IftgFqwNVxaQjshYvKbONd70c+QjJI4 xPXydF31BsNxaML6ZtCH9N9RQQAJrKUXpFmWr4pOeExLXh2yJI8Uusp1eUAsJhUKp9dP +fpfgHLgd08Dbv7M4tIuncfEMcSGhnDEweuayZbaxmCB6PMYE8HRomHLBDY3cwknDjyv HAJVHxT1RUUw6lcpaFdrkMWZMgNmbHVIbf3hia8I8+tMPCGgajPSlTSXQcEAx+XaOibh YSqwuwfzn4DwXXzXe9XA/r9bMMfqvp15+ObE0XRKjG6X91q4p1HHXjWnukLsv4GyOFGA Oz4w== X-Gm-Message-State: ALoCoQlLBxgES/NM/VHx0imN3eOWyCRRiyEberuuHrZXgITycSJOv9X7MUSOSI2f8MGwsz5it42R X-Received: by 10.194.104.201 with SMTP id gg9mr28544314wjb.113.1429523424422; Mon, 20 Apr 2015 02:50:24 -0700 (PDT) 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 ei4sm2392760wib.22.2015.04.20.02.50.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 02:50:23 -0700 (PDT) Message-ID: <5534CBE5.1020902@multiplay.co.uk> Date: Mon, 20 Apr 2015 10:50:29 +0100 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: ZFS: exclude one FS from recurive snapshot creation? Or some equivalent to "nodump" for dataset? References: <710623939.20150420122931@serebryakov.spb.ru> In-Reply-To: <710623939.20150420122931@serebryakov.spb.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.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 09:50:32 -0000 Thinking outside the box a little, create the recursive snapshot then remove the snapshot for that user? On 20/04/2015 10:29, Lev Serebryakov wrote: > Hello Freebsd-fs, > > I have set of ZFS filesystems, one fielsystem per user like this: > > zroot/home/group1/user11 > zroot/home/group1/user12 > zroot/home/group1/user13 > zroot/home/group2/user21 > zroot/home/group2/user22 > zroot/home/group3/user31 > ... > > I want to create complete snapshots of "zroot/home" tree regularly (with > zfSnap), but I have one "user" which holds a huge amount of > easy-reconstructible data, which I don't wont to store in snapshots. > > Is it possible to exclude one dataset (filesystem) from "zfs snap -r"? > > I don't want to enumerate all but this filesystem in configuration file, as > it is error-prone and requires editing configs each time user is created or > removed. > > P.S. I start to understand how much I love "nodump" flag on UFS and it usage > with "dump" command! Absence of such functionality for "zfs send" is really > pity. > From owner-freebsd-fs@FreeBSD.ORG Tue Apr 21 06:14:14 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 ED8D9696 for ; Tue, 21 Apr 2015 06:14:14 +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 D949216F7 for ; Tue, 21 Apr 2015 06:14:14 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3L6EEjH062129 for ; Tue, 21 Apr 2015 06:14:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 199189] SWAP on ZFS can crash server Date: Tue, 21 Apr 2015 06:14:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: vermaden@interia.pl 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.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 06:14:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199189 --- Comment #7 from vermaden@interia.pl --- So a rule of thumb can be something like this? vm.v_free_min = 3 * RAM (GB) * 1024 vm.v_free_severe = 3 * RAM (GB) * 1024 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 21 17:57:59 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 DEFA718B for ; Tue, 21 Apr 2015 17:57:59 +0000 (UTC) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (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 B418817FC for ; Tue, 21 Apr 2015 17:57:59 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 1D6DC194D for ; Tue, 21 Apr 2015 13:57:51 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Tue, 21 Apr 2015 13:57:51 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=g9sZbSpDKpvF8nP X4NTJ5yVmIXo=; b=AYuHLOuI6Lh64qU5f/TeeY27zOGFki3atAM3YWI6RixH1TM T36Mqv5hnNJ07274rRMM1msb6hj9+6HFQ1WxrANTISunjVBcLw44VrqBB4LiWTfM eXxNvIPJpZL7mHAYPqD15se7CrNJXkEX0n0DfItQROCjyEePrj/vYX/BdzOE= Received: by web3.nyi.internal (Postfix, from userid 99) id BC52110C160; Tue, 21 Apr 2015 13:57:50 -0400 (EDT) Message-Id: <1429639070.964197.256736865.55BDAF8C@webmail.messagingengine.com> X-Sasl-Enc: iEthPDotDbLeOeNHT/kKX1TLaQ6QaJO+3zxp4wbR/Hlu 1429639070 From: Mark Felder To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-424f40c2 Subject: Re: ZFS: exclude one FS from recurive snapshot creation? Or some equivalent to "nodump" for dataset? Date: Tue, 21 Apr 2015 12:57:50 -0500 In-Reply-To: <710623939.20150420122931@serebryakov.spb.ru> References: <710623939.20150420122931@serebryakov.spb.ru> X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 17:58:00 -0000 On Mon, Apr 20, 2015, at 04:29, Lev Serebryakov wrote: > Hello Freebsd-fs, > > I have set of ZFS filesystems, one fielsystem per user like this: > > zroot/home/group1/user11 > zroot/home/group1/user12 > zroot/home/group1/user13 > zroot/home/group2/user21 > zroot/home/group2/user22 > zroot/home/group3/user31 > ... > > I want to create complete snapshots of "zroot/home" tree regularly (with > zfSnap), but I have one "user" which holds a huge amount of > easy-reconstructible data, which I don't wont to store in snapshots. > > Is it possible to exclude one dataset (filesystem) from "zfs snap -r"? > > I don't want to enumerate all but this filesystem in configuration file, > as > it is error-prone and requires editing configs each time user is created > or > removed. > > P.S. I start to understand how much I love "nodump" flag on UFS and it > usage > with "dump" command! Absence of such functionality for "zfs send" is > really > pity. > You have to grow the snapshot tool yourself, but it's possible. The zfs snapshot -r will not understand this though. zfstools is a utility to manage your snapshots and it uses zfs attributes to let you disable snapshots for a filesystem: zfs set com.sun:auto-snapshot -- that's an entirely fabricated attribute that the tool looks for so it knows to skip the snapshot. Check it out: https://github.com/bdrewery/zfstools From owner-freebsd-fs@FreeBSD.ORG Wed Apr 22 09:25:49 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 4CD82ECC for ; Wed, 22 Apr 2015 09:25:49 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (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 A84B01778 for ; Wed, 22 Apr 2015 09:25:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id t3M9N2UJ095350; Wed, 22 Apr 2015 12:23:02 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Wed, 22 Apr 2015 12:23:02 +0300 (MSK) From: Dmitry Morozovsky To: Steven Hartland cc: freebsd-fs@freebsd.org Subject: Re: ZFS: exclude one FS from recurive snapshot creation? Or some equivalent to "nodump" for dataset? In-Reply-To: <5534CBE5.1020902@multiplay.co.uk> Message-ID: References: <710623939.20150420122931@serebryakov.spb.ru> <5534CBE5.1020902@multiplay.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Wed, 22 Apr 2015 12:23:52 +0300 (MSK) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 09:25:49 -0000 On Mon, 20 Apr 2015, Steven Hartland wrote: > Thinking outside the box a little, create the recursive snapshot then remove > the snapshot for that user? or, even invent your own property like zfs set org.freebsd:nosend=yes pool/path/to/fs and then (could be optimized, but): zfs snap pool@snapname zfs get -H -o name,value -t snapshot org.freebsd:nosend | \ awk '$2 == "yes" {print $1}' | \ xargs -n1 zfs destroy ? > > On 20/04/2015 10:29, Lev Serebryakov wrote: > > Hello Freebsd-fs, > > > > I have set of ZFS filesystems, one fielsystem per user like this: > > > > zroot/home/group1/user11 > > zroot/home/group1/user12 > > zroot/home/group1/user13 > > zroot/home/group2/user21 > > zroot/home/group2/user22 > > zroot/home/group3/user31 > > ... > > > > I want to create complete snapshots of "zroot/home" tree regularly (with > > zfSnap), but I have one "user" which holds a huge amount of > > easy-reconstructible data, which I don't wont to store in snapshots. > > > > Is it possible to exclude one dataset (filesystem) from "zfs snap -r"? > > > > I don't want to enumerate all but this filesystem in configuration file, > > as > > it is error-prone and requires editing configs each time user is created or > > removed. > > > > P.S. I start to understand how much I love "nodump" flag on UFS and it usage > > with "dump" command! Absence of such functionality for "zfs send" is really > > pity. > > > > _______________________________________________ > 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" > -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Wed Apr 22 21:20:35 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 A3D537C1 for ; Wed, 22 Apr 2015 21:20:35 +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 8EE4F1738 for ; Wed, 22 Apr 2015 21:20:35 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3MLKZcx072741 for ; Wed, 22 Apr 2015 21:20:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 199189] SWAP on ZFS can crash server Date: Wed, 22 Apr 2015 21:20:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: marcus@blazingdot.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: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 21:20:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199189 marcus@blazingdot.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marcus@blazingdot.com --- Comment #8 from marcus@blazingdot.com --- For what it's worth, I've been doing swap on a zvol for a long time now on -CURRENT without problems. Using "-o checksum=off -o compression=off -o dedup=off -o sync=disabled -o primarycache=none" seems to be key. I've hammered on it quite a bit to try and get it to crash. My memory allocator looks different from yours; this one is faster but just sets the memory to zeroes with explicit_bzero(). #include #include #include #define HUNK 1048576 int main(void) { unsigned long long i; for(i = 0 ; ; i++) { explicit_bzero(malloc(HUNK), HUNK); printf("\r%llu", i * HUNK); fflush(stdout); }; return(EXIT_SUCCESS); } -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Wed Apr 22 21:22:25 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 0D222846 for ; Wed, 22 Apr 2015 21:22:25 +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 EC70B174E for ; Wed, 22 Apr 2015 21:22:24 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3MLMOWG077430 for ; Wed, 22 Apr 2015 21:22:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 199189] SWAP on ZFS can crash server Date: Wed, 22 Apr 2015 21:22:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: vermaden@interia.pl 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.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 21:22:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199189 --- Comment #9 from vermaden@interia.pl --- @marcus@blazingdot.com Have You tried the 'perl' one? (not mine unfortunatelly, got it from someone) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Wed Apr 22 21:23:02 2015 Return-Path: Delivered-To: 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 2C6058B9 for ; Wed, 22 Apr 2015 21:23:02 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 E39B61755 for ; Wed, 22 Apr 2015 21:23:01 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id D3E2F16A572 for ; Wed, 22 Apr 2015 23:22:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uDrp0TniJRo; Wed, 22 Apr 2015 23:22:49 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:f9ee:b7ef:2371:dea6] (unknown [IPv6:2001:4cb8:3:1:f9ee:b7ef:2371:dea6]) by smtp.digiware.nl (Postfix) with ESMTPA id 60EB616A574 for ; Wed, 22 Apr 2015 23:22:49 +0200 (CEST) Message-ID: <55381127.4090603@digiware.nl> Date: Wed, 22 Apr 2015 23:22:47 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: fs@freebsd.org Subject: resampeling of a ZVOL that has been resized Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 21:23:02 -0000 Hi, I'm trying to do some tests with resizing/growfsing partitions because an earlier attempt for a online system did not work as expected. So I first create ZVOL, format it and then mount it. Fill it with some data. And then grow it ---- zfs create -V 100G $VOL gpart create -s GPT $DEV gpart add -t freebsd-ufs -l test $DEV newfs $DISK mount $DISK $MNT rsync -rav /usr/src/ $MNT zfs set volsize=200G $VOL ---- Now gpart show gives me: => 40 209715120 zvol/zfsdata/vol GPT (200G) 40 8 - free - (4.0K) 48 209715104 1 freebsd-ufs (100G) 209715152 8 - free - (4.0K) But I'm not able to grow partition 1.... Only once the system is rebooted is get: => 40 209715120 zvol/zfsdata/vol GPT (200G) [CORRUPT] 40 8 - free - (4.0K) 48 209715104 1 freebsd-ufs (100G) 209715152 8 - free - (4.0K) 'gpart recover zvol/zfsdata/vol' then recovers the GPT data. After which we can resize the partition: 'gpart resize -i 1 zvol/zfsdata/vol' And even when the partion is mounted growfs does its work and resizes with a few seconds to the full size.... Now the question: How can I get GEOM to resample the zvol, and have it really detect that the disk has changed.... It sort of does, but not enough to actually allow it to grow to the new size. Thanx, --WjW From owner-freebsd-fs@FreeBSD.ORG Wed Apr 22 21:26:12 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 DF22996F for ; Wed, 22 Apr 2015 21:26:12 +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 CA0901783 for ; Wed, 22 Apr 2015 21:26:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3MLQCbM078731 for ; Wed, 22 Apr 2015 21:26:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 199189] SWAP on ZFS can crash server Date: Wed, 22 Apr 2015 21:26:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: vermaden@interia.pl 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.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 21:26:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199189 --- Comment #10 from vermaden@interia.pl --- I agree on most of these options for SWAP ZVOL, but using 'compression=off' instead of 'compression=lz4' seems to be big 'loss' ... also in term of IOPS because You need to allocate less blocks for the same data. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Wed Apr 22 21:41: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 14C3CEC7 for ; Wed, 22 Apr 2015 21:41: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 F3C2D197A for ; Wed, 22 Apr 2015 21:41:30 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3MLfUG2094402 for ; Wed, 22 Apr 2015 21:41:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 199189] SWAP on ZFS can crash server Date: Wed, 22 Apr 2015 21:41: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: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: marcus@blazingdot.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.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 21:41:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199189 --- Comment #11 from marcus@blazingdot.com --- > Have You tried the 'perl' one? (not mine unfortunatelly, got it from someone) I ran it a few times (it is quite fast.) right in the middle of a 'make -j16 buildkernel' compile with several Chrome windows up. No problems, process is killed when swap is exhausted. Aside from setting the properties on the zroot/swap dataset, I have done no zfs-related tuning. I'm running recent -CURRENT on amd64 with 8GB RAM, 2GB swap zvol on an SSD. Swap on zvol has been rock solid for me since I started using it again after the ARC/UMA rebalance/low memory handling fix that happened last year. I would be happy to tweak things to try to get it to crash if you have some tunables that you would like to test. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Wed Apr 22 22:09:00 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 D0ED9AD9 for ; Wed, 22 Apr 2015 22:09:00 +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 BBC181C2E for ; Wed, 22 Apr 2015 22:09:00 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3MM90bF045926 for ; Wed, 22 Apr 2015 22:09:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 199189] SWAP on ZFS can crash server Date: Wed, 22 Apr 2015 22:09:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: vermaden@interia.pl 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.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 22:09:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199189 --- Comment #12 from vermaden@interia.pl --- @marcus@blazingdot.com Currently only 'compression=lz4' comes to my mind. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu Apr 23 05:06:47 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 2F1489D for ; Thu, 23 Apr 2015 05:06:47 +0000 (UTC) Received: from aur.1dianliulan.com (aur.1dianliulan.com [23.92.219.77]) by mx1.freebsd.org (Postfix) with ESMTP id B699B1704 for ; Thu, 23 Apr 2015 05:06:46 +0000 (UTC) To: freebsd-fs@freebsd.org Subject: business leads Message-ID: Date: Thu, 23 Apr 2015 06:54:38 +0200 From: "John" Reply-To: healerc@tom.com MIME-Version: 1.0 X-Mailer-LID: 5 X-Mailer-RecptId: 6480514 X-Mailer-SID: 282 X-Mailer-Sent-By: 1 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 05:06:47 -0000 Hey, You are receiving this email because we wish you to use our email marketing service. We wish to be your email marketing partner, we can grow your business 2-5 times than now. If you would require more information please send us an email and we would be glad to discuss the project requirements with you soon. Looking forward to your positive response. Kind Regards John Email: pottleyo@aliyun.com ------------------------------------------------- This e-mail message and its attachments (if any) are intended solely for the use of the addressee(s) hereof. In addition, this message and the attachments (if any) may contain information that is confidential, privileged and exempt from disclosure under applicable law. If you are not the intended recipient of this message, you are prohibited from reading, disclosing, reproducing, distributing, disseminating or otherwise using this transmission. Delivery of this message to any person other than the intended recipient is not intended to waive any right or privilege. If you have received this message in error, please promptly notify the sender and immediately delete this message from your system. If you don't wish our future news letter, pls send address to ttickmay@aliyun.com for removal. From owner-freebsd-fs@FreeBSD.ORG Thu Apr 23 17:39: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 EE01BDEB for ; Thu, 23 Apr 2015 17:39:04 +0000 (UTC) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies, LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DED01C83 for ; Thu, 23 Apr 2015 17:39:04 +0000 (UTC) Received: from torb.pix.net (verizon.pix.net [71.178.232.3]) (authenticated bits=0) by hydra.pix.net (8.15.1/8.15.1) with ESMTPA id t3NHd2i0064159; Thu, 23 Apr 2015 13:39:02 -0400 (EDT) (envelope-from lidl@pix.net) X-Authentication-Warning: hydra.pix.net: Host verizon.pix.net [71.178.232.3] claimed to be torb.pix.net Message-ID: <55392E36.6070209@pix.net> Date: Thu, 23 Apr 2015 13:39:02 -0400 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: creating new zpool under jail? Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:39:05 -0000 Greetings - I've run into a problem that I haven't been able to figure out how to work around, and after looking through some of the kernel code, I'm not sure it is currently possible to do what I want. I have a script that creates a 2GB file, and then creates a fresh zpool using that file as the backing store. That works perfectly on a regular machine. I can create the zpool and some filesystems, and when I'm done, use 'zfs send' to serialize the contents of the filesystems into a static set of files. Here's the commands from that script: mkdir zfs truncate -s +2g zfs.file zpool create -o cachefile=none -m `pwd`/zfs system `pwd`/zfs.file When run on a jailed instance, the 'zpool create' fails like this: zpool create -o cachefile=none -m `pwd`/zfs system `pwd`/zfs.file cannot create 'system': 'mountpoint' cannot be set while dataset 'zoned' property is set So, changing it slightly to work around the "zoned" issue: zpool create -o cachefile=none -O jailed=on \ -m `pwd`/zfs system `pwd`/zfs.file cannot create 'system': permission denied Using ktrace/kdump on the command under the jail, it fails with: 4832 zpool SCTL "sysctl.name2oid" 4832 zpool RET __sysctl 0 4832 zpool CALL __sysctl(0x7fffffffb700,0x3,0x7fffffffb7a4,0x7fffffffb7a8,0,0) 4832 zpool SCTL "security.jail.jailed" 4832 zpool RET __sysctl 0 4832 zpool CALL __sysctl(0x7fffffffb8e0,0x2,0x7fffffffb920,0x7fffffffb918,0x801473dfd,0x15) 4832 zpool SCTL "sysctl.name2oid" 4832 zpool RET __sysctl 0 4832 zpool CALL __sysctl(0x7fffffffb920,0x4,0x7fffffffb9cc,0x7fffffffb9d0,0,0) 4832 zpool SCTL "vfs.zfs.version.ioctl" 4832 zpool RET __sysctl 0 4832 zpool CALL ioctl(0x3,0xc0185a00,0x7fffffffb950) 4832 zpool RET ioctl -1 errno 1 Operation not permitted I would think that creating a file-backed zpool under a jail ought to be allowed. Any suggestions/solutions welcomed! Thanks for reading. -Kurt From owner-freebsd-fs@FreeBSD.ORG Fri Apr 24 02:58:10 2015 Return-Path: Delivered-To: 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 D34BD3E6 for ; Fri, 24 Apr 2015 02:58:10 +0000 (UTC) Received: from forward3l.mail.yandex.net (forward3l.mail.yandex.net [IPv6:2a02:6b8:0:1819::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 914811598 for ; Fri, 24 Apr 2015 02:58:10 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [IPv6:2a02:6b8:0:f05::117]) by forward3l.mail.yandex.net (Yandex) with ESMTP id 1DBB915012E7; Fri, 24 Apr 2015 05:57:56 +0300 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id 7F7281B47EF3; Fri, 24 Apr 2015 05:57:55 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:6::a8]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id REm70IMIXK-vshWSmhs; Fri, 24 Apr 2015 05:57:55 +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=1429844275; bh=Z7VEmTk7Be8TTs8T24aehiPdXU+cPRvIGRqUoKjJ8mY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=eMFK4W9p+SXHU+GUm+ZweMTPAPCcDFYYzqKCGpNwE1usod9IjMWMciHfx+3evgZbJ sJHaLpMPZcWCVtQfXfbTDeGP+WaiHNG2MIPwHf1eUGgmFUqo/TT/mEm49sM2Hh38T5 hl7GjgYB6KwhaOjnPlJxEivwor8irSxMvNpC1kD4= Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5539B0C4.6070000@yandex.ru> Date: Fri, 24 Apr 2015 05:56:04 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Willem Jan Withagen , fs@freebsd.org Subject: Re: resampeling of a ZVOL that has been resized References: <55381127.4090603@digiware.nl> In-Reply-To: <55381127.4090603@digiware.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 02:58:10 -0000 On 23.04.2015 00:22, Willem Jan Withagen wrote: > Now the question: > How can I get GEOM to resample the zvol, and have it really detect that > the disk has changed.... It sort of does, but not enough to actually > allow it to grow to the new size. You need to read dmesg, where you will find the message: GEOM_PART: zvol/zfsdata/vol was automatically resized. Use `gpart commit zvol/zfsdata/vol` to save changes or `gpart undo zvol/zfsdata/vol` to revert them. -- WBR, Andrey V. Elsukov From owner-freebsd-fs@FreeBSD.ORG Sat Apr 25 10:53:04 2015 Return-Path: Delivered-To: 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 932DC26F for ; Sat, 25 Apr 2015 10:53:04 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 5675111BD for ; Sat, 25 Apr 2015 10:53:04 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id B16F916A47A; Sat, 25 Apr 2015 12:52:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNHjnX47Hs5T; Sat, 25 Apr 2015 12:52:50 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:9d5b:6fac:30b6:fba1] (unknown [IPv6:2001:4cb8:3:1:9d5b:6fac:30b6:fba1]) by smtp.digiware.nl (Postfix) with ESMTPA id 0FB2B16A46F; Sat, 25 Apr 2015 12:52:50 +0200 (CEST) Message-ID: <553B7200.7090002@digiware.nl> Date: Sat, 25 Apr 2015 12:52:48 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , fs@freebsd.org Subject: Re: resampeling of a ZVOL that has been resized References: <55381127.4090603@digiware.nl> <5539B0C4.6070000@yandex.ru> In-Reply-To: <5539B0C4.6070000@yandex.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 10:53:04 -0000 On 24/04/2015 04:56, Andrey V. Elsukov wrote: > On 23.04.2015 00:22, Willem Jan Withagen wrote: >> Now the question: >> How can I get GEOM to resample the zvol, and have it really detect that >> the disk has changed.... It sort of does, but not enough to actually >> allow it to grow to the new size. > > You need to read dmesg, where you will find the message: > GEOM_PART: zvol/zfsdata/vol was automatically resized. > Use `gpart commit zvol/zfsdata/vol` to save changes or > `gpart undo zvol/zfsdata/vol` to revert them. > This does not really resolve the issue. after growing the volume in ZFS, the new size is reported in ' gpart show': freetest# gpart show zvol/zfsdata/vol => 40 209715120 zvol/zfsdata/vol GPT (200G) 40 8 - free - (4.0K) 48 209715104 1 freebsd-ufs (100G) 209715152 8 - free - (4.0K) However the free space at the end stays at a mere 4.0K, not allowing gpart resize to take any value other than less than 100G, effectively shrinking the partition. And there is no incantation of any of commit, recover, etc... to get gpart to actually do "the right thing" When I did this on a VMware VM, gpart show reported the volume as [CORRUPTED] and gpart recover fixed that. Supposedly the backup blocks were at the wrong place in the grown disk and recover again placed them at the end. But the ZFS case does not go into the [CORRUPTED] state. Perhaps that is due to also missing the message that you suggest that can be found in dmesg after resizing the ZVOL. And thus a recover is not needed, nor dies issueing it fix anything. Now after a reboot the bootup log tells: GEOM: zvol/zfsdata/vol: the secondary GPT header is not in the last LBA. And now gpart report as expected: => 40 209715120 zvol/zfsdata/vol GPT (200G) [CORRUPT] 40 8 - free - (4.0K) 48 209715104 1 freebsd-ufs (100G) 209715152 8 - free - (4.0K) gpart recover sets the free space to 100G: => 40 419430320 zvol/zfsdata/vol GPT (200G) 40 8 - free - (4.0K) 48 209715104 1 freebsd-ufs (100G) 209715152 209715208 - free - (100G) And from now on I can resize the partition 1 to 200G... So it seems that although gpart understands that the ZVOL volume has grown, it does not take it far enough and set it to CORRUPTED and then let the user correct/grow it. --WjW From owner-freebsd-fs@FreeBSD.ORG Sat Apr 25 16:50:25 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 C6030308 for ; Sat, 25 Apr 2015 16:50:25 +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 B171012DF for ; Sat, 25 Apr 2015 16:50:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3PGoPSe026655 for ; Sat, 25 Apr 2015 16:50:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 199675] zfs scrubbing and resilvering speed report overflow Date: Sat, 25 Apr 2015 16:50:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 16:50:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199675 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sat Apr 25 16:53:36 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 4FC7852A for ; Sat, 25 Apr 2015 16:53:36 +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 3B2B41314 for ; Sat, 25 Apr 2015 16:53:36 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3PGrak9032791 for ; Sat, 25 Apr 2015 16:53:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 199574] trim load ssd on 100% Date: Sat, 25 Apr 2015 16:53:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 16:53:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199574 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug.