From owner-freebsd-fs@freebsd.org Sun Nov 6 21:00:49 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E956BC343F0 for ; Sun, 6 Nov 2016 21:00:49 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB3FE94E for ; Sun, 6 Nov 2016 21:00:49 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uA6L01Ax009795 for ; Sun, 6 Nov 2016 21:00:49 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201611062100.uA6L01Ax009795@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention Date: Sun, 06 Nov 2016 21:00:49 +0000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2016 21:00:50 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 203492 | mount_unionfs -o below causes panic Open | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 140068 | [smbfs] [patch] smbfs does not allow semicolon in Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f Open | 203419 | solaris assert: (dn->dn_phys->dn_nlevels == 0 && Open | 211491 | System hangs after "Uptime" on reboot with ZFS 7 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Sun Nov 6 23:45:53 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A08BC34109 for ; Sun, 6 Nov 2016 23:45:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 29D45E8F for ; Sun, 6 Nov 2016 23:45:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uA6Njq0c091761 for ; Sun, 6 Nov 2016 23:45:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 214265] zfs is broken in stable/11 Date: Sun, 06 Nov 2016 23:45:52 +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-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2016 23:45:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214265 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org Keywords| |regression --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Nov 7 00:58:23 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C58FFC33848 for ; Mon, 7 Nov 2016 00:58:23 +0000 (UTC) (envelope-from m-51d9v4vb7r2iy85uxyzozc2fselav4qe3ogcvzfxm46yz6ndjbnj60s0@bounce.linkedin.com) Received: from maile-be.linkedin.com (maile-be.linkedin.com [IPv6:2620:109:c006:104::205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.linkedin.com", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81601D8A for ; Mon, 7 Nov 2016 00:58:23 +0000 (UTC) (envelope-from m-51d9v4vb7r2iy85uxyzozc2fselav4qe3ogcvzfxm46yz6ndjbnj60s0@bounce.linkedin.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1478480292; bh=ZOJHLvl4X8Xdeka3+iXs3DFYL4A1y1R3TZPotPcTBEo=; h=From:Subject:MIME-Version:Content-Type:To:Date:X-LinkedIn-Class: X-LinkedIn-Template:X-LinkedIn-fbl; b=FMSE5ueQz81weMzDa7TccHLK+pgm7wLObSrArEVIoksQekjhbjaBBqmidWdg8Keoa 6QvPwB/KIaF9sUCYejDmpnaxukbFO4mkrRjFhXW6gCFG/i9dS7a6mm4A00TiGVGBON qJ+1tsN2XUF/iuoEbuvBgemnvy5b0xsphynywmm4= From: Juergen Gotteswinter Message-ID: <1542688453.83573.1478480292406.JavaMail.app@lva1-app4073.prod.linkedin.com> Subject: =?UTF-8?Q?Gr=C3=BC=C3=9Fe_von_Juergen_Gotteswinter?= MIME-Version: 1.0 To: Date: Mon, 7 Nov 2016 00:58:12 +0000 (UTC) X-LinkedIn-Class: INVITE-GUEST X-LinkedIn-Template: invite_guest X-LinkedIn-fbl: m2-at00iw5qc1pom62e8wn6drakx196m7meit85peaentxsetjextdu8ydrr53mlcizzq8deegfyhy9qyyjmbchvo0et9q2o4el2y1efl X-LinkedIn-Id: 0-iv7czp7b-hp Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 00:58:23 -0000 Ich m=C3=B6chte Dich gerne zu meinem beruflichen Netzwerk auf LinkedIn hinz= uf=C3=BCgen. Juergen Gotteswinter Juergen Gotteswinters Profil anzeigen https://www.linkedin.com/comm/start/a= ccept-invitation?sharedKey=3Da5dzqhqq&invitationId=3D6201195577242329108&tr= k=3Deml-invite_guest-invite_guest-110-germany_f_v2_b&trkEmail=3Deml-invite_= guest-invite_guest-110-germany_f_v2_b-null-0%7Eiv7czp7b%7Ehp Sie haben eine Einladung zur Kontaktaufnahme erhalten. Ihre E-Mail-Adresse = wird in Funktionen wie =E2=80=9EPersonen, die Sie vielleicht kennen=E2=80= =9C verwendet, um Kontaktvorschl=C3=A4ge zu machen. Hier abbestellen: https= ://www.linkedin.com/e/v2?e=3D0-iv7czp7b-hp&t=3Dlun&midToken=3DAQFmrFVhGEd36= Q&ek=3Dinvite_guest&loid=3DAQFeIHTTVbJX3gAAAVg8Sungi5h64F6NWWKwwZXe1FZi6XuR= WnOpSzmOF7QhReaRAb7_j5NPvWRwWK6KW84&eid=3D0-iv7czp7b-hp Diese E-Mail wurde an freebsd-fs@freebsd.org gesendet. If you need assistance or have questions, please contact LinkedIn Customer = Service: https://www.linkedin.com/e/v2?e=3D0-iv7czp7b-hp&a=3DcustomerServic= eUrl&ek=3Dinvite_guest © 2016 LinkedIn Corporation, 2029 Stierlin Court, Mountain View CA 940= 43. LinkedIn und das LinkedIn Logo sind eingetragene Marken von LinkedIn. From owner-freebsd-fs@freebsd.org Mon Nov 7 05:12:54 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CEB04C344BE for ; Mon, 7 Nov 2016 05:12:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE64C65C for ; Mon, 7 Nov 2016 05:12:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uA75CsFS068633 for ; Mon, 7 Nov 2016 05:12:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 214265] zfs is broken in stable/11 Date: Mon, 07 Nov 2016 05:12:54 +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-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: Mathias.Picker@virtual-earth.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 05:12:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214265 Mathias.Picker@virtual-earth.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Mathias.Picker@virtual-eart | |h.de --- Comment #1 from Mathias.Picker@virtual-earth.de --- I can confirm the broken zfs/zpool on my system: gucky% uname -a FreeBSD gucky 11.0-STABLE FreeBSD 11.0-STABLE #1 r308107: Sun Oct 30 19:48:= 10 CET 2016 mathiasp@gucky:/usr/obj/usr/src/sys/GUCKY amd64 gucky% zpool internal error: failed to initialize ZFS library gucky% zfs internal error: failed to initialize ZFS library But I could boot just fine. Lucky me ;) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Nov 7 09:47:45 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD5C0C32398 for ; Mon, 7 Nov 2016 09:47:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BCFDC83C for ; Mon, 7 Nov 2016 09:47:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uA79ljea050419 for ; Mon, 7 Nov 2016 09:47:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 214265] zfs is broken in stable/11 Date: Mon, 07 Nov 2016 09:47:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: laszlo@karolyi.hu X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 09:47:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214265 --- Comment #2 from L=C3=A1szl=C3=B3 K=C3=A1rolyi --- Okay, the fault with the rebooting is on my behalf, I forgot the 'da' driver from the kernel config, thus the kernel couldn't find my ada drives. After adding that, the reboot worked. And, after reboot, the zfs binaries work again. I don't know if this is still considered a bug, but before the reboot, the problem persists. Someone close this bug if it deems to be closed, I'll just leave it open. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Nov 7 10:28:03 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB53EC331AC for ; Mon, 7 Nov 2016 10:28:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0057.outbound.protection.outlook.com [157.56.111.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DC23F74 for ; Mon, 7 Nov 2016 10:28:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Sun, 6 Nov 2016 20:51:25 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0707.006; Sun, 6 Nov 2016 20:51:25 +0000 From: Rick Macklem To: "freebsd-fs@freebsd.org" Subject: Mount protocol/showmount vs NFSv4 Thread-Topic: Mount protocol/showmount vs NFSv4 Thread-Index: AQHSOG1Vi/9I8/Ov0UO2Epz4od6j/g== Date: Sun, 6 Nov 2016 20:51:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: aed86fd4-202b-4c87-f1bf-08d40686aca6 x-microsoft-exchange-diagnostics: 1; YTXPR01MB0189; 7:A3A21ZaN4PyBJzk9ZW7F0nOou7hc1pNRXtLc1xpFVo2BK4wlhFUhXPp8JX4wr2TzY7vrp1G7Vl8iZOn1CU6YWO5Qr9bhzEmPANlwnHWJlM3bHp/XSpSVSyelVAhy86dpZtjHh1xBDxC/AbPiKZSuBcByPGCoH0Mik201hFiBOYluJPoagYH2qNwefoIWr9am1Pp3d74kDQdsgMPEpVa9mIN8e3xcjA2zpMHkxUypZMYQjstOEGtseWcDWju9XBbk/Q/QuKD5lHodboqS+rndwRIMdAiCx3wFKrvtOxsMCuzzZUZ/hvy6O+2WpW1y5j5FEoNwG9G/hsmjsTAl2a+K8erlhxO/KN+IN/K8Ozlqvl4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:YTXPR01MB0189; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6043046)(6042046); SRVR:YTXPR01MB0189; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0189; x-forefront-prvs: 0118CD8765 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(81166006)(2906002)(97736004)(11100500001)(107886002)(101416001)(81156014)(6916009)(122556002)(7846002)(8676002)(450100001)(105586002)(5660300001)(2501003)(77096005)(106116001)(8936002)(74482002)(2900100001)(68736007)(50986999)(7696004)(2351001)(229853001)(106356001)(9686002)(86362001)(189998001)(110136003)(5002640100001)(33656002)(3280700002)(102836003)(10400500002)(305945005)(586003)(3660700001)(54356999)(92566002)(5640700001)(74316002)(87936001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0189; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2016 20:51:25.7448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0189 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 10:28:04 -0000 Hi, NFSv2 and NFSv3 use a protocol called Mount (implemented by mountd) to try = and track mounts/unmounts and report exports to clients. Except for the one RPC= that maps a directory path to a File Handle, none of this is needed by NFS. The = rest is reported (and never guaranteed to be correct) by showmount(8). There are a couple of issues related to the Mount protocol. 1 - It uses a dynamically assigned port# via rpcbind (which means hassles f= or firewalls, etc). 2 - umount(8) currently assumes that it is supported over UDP and fails if = it is configured to work over TCP only. 3 - A recent issue was reported where there is a delay for systems configur= ed for IP6 only related to the handling of localhost. (I'll admit I didn't unders= tand quite why there was this 2sec delay, but others familiar with networking confirm= ed it was correct behaviour.) NFSv4 doesn't use the Mount protocol at all and does everything via the NFS= v4 protocol serviced at port #2049. I have never done anything about this, since most were still using NFSv3, b= ut it seems that maybe something should be done now? - What do people think of having a new option on mountd(8) that would be us= ed for NFSv4 only servers that disables servicing of Mount RPCs. --> This would imply that "showmount" would no longer work for it. --> Note that "showmount" returns nothing useful for NFSv4 mounts,= since mountd doesn't know about NFSv4 mounts (and the NFSv4 server doesn'= t know either, because there is no concept of a "mount" in the NFSv4 protoc= ol). --> It does imply that "showmount -e" will stop working and that in= fo might be useful w.r.t. NFSv4 servers. Umount(8) for NFSv3 is a slightly different problem. It has (for 30years) j= ust talked to UDP. If that doesn't work, there is a delay, but the umount still works (an= d the info from "showmount" is no longer correct, but it is never guaranteed to be cor= rect anyhow). - Should umount(8) use TCP if the NFSv3 mount is using TCP? --> This could cause it to break for a case where only UDP is supported f= or the Mount protocol on the server, but that would be a rare/broken case, I'd g= uess. Anyhow, any/all comments on this would be appreciated, rick From owner-freebsd-fs@freebsd.org Mon Nov 7 10:48:21 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D1E2C336BE for ; Mon, 7 Nov 2016 10:48:21 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 DBCCFAEA for ; Mon, 7 Nov 2016 10:48:20 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by mail-it0-x22d.google.com with SMTP id q124so14570958itd.1 for ; Mon, 07 Nov 2016 02:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Lwf3Uvw0PXlBBCPA2j8Nnmwo+QVferIynE1LvK+KllY=; b=bGrfiRnjLI0tzNZikENFTXshvfxXKSjnlOQjmR9Zato9qjVZXPHRcMo5A0KqpAwnoi NePBa9+4TH9MRkpERUM9jywxFQ3aHo4dY+8A768ec6FPF/c4bjUqMZVY+QPox3OXtxwy xxVujSo0pcREJMpwsmr7n7sBQSNtj4V5QFYg5oF43G4UzgQGlyOG5mGDiqbsvvYzllhj vAwEUp4j2+H7bxCAHC8qPZ8r0j9y75vTzp067/HJ7AzMV8Z7JG5LIOe0YuQtmcmMEAHi F6Hhjvm7HN+X7hw8f1RGeH2ZLXB52PW+IINZZiwtUzM3iNJPICGbU2bYMR3AWgmQndmo vNoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Lwf3Uvw0PXlBBCPA2j8Nnmwo+QVferIynE1LvK+KllY=; b=Es6mrH1l42rbQx9Ni1gUBS6h+8cffQpdU0cXeSeV0pEcTfARBPv66tIt5ANWEFELd4 +2cNYTI4pH5BBkpBhbsLEfCm1C3Ag+O8bPT2VkKmp1KPDduxchCwH5Q3vNL77MKuxPoU AlUn6NE9cepQHWxTzeU7SkJD+o5+79ljV/y0/gfoQJzCgIQtadpaqzYC7zqKAwiZpY30 EQMl8dZBZXu+xalkeCpeDK2gU1dLcAkIL6eq4isREYT3rt4pGtlDY5nMxoiQKBnDiOZV 0JtJM2Meh68Yr/NQsjW8po1vPrh6bTciPCsdDkrDVc+QvpU3aKLRr4Xi8q6dWuPW9ekN mnMA== X-Gm-Message-State: ABUngvcdOfno6WszeZoCdduS8bfoUXoPR1xpzU9QFgzrbSavfyFvgnVTyxFPBGAR+aKTkkFtikqHhaKQCJGAgg== X-Received: by 10.202.194.68 with SMTP id s65mr3639730oif.98.1478515699684; Mon, 07 Nov 2016 02:48:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.165.138 with HTTP; Mon, 7 Nov 2016 02:48:19 -0800 (PST) In-Reply-To: References: From: Doug Rabson Date: Mon, 7 Nov 2016 10:48:19 +0000 Message-ID: Subject: Re: Mount protocol/showmount vs NFSv4 To: Rick Macklem Cc: "freebsd-fs@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 10:48:21 -0000 It seems like a reasonably good idea to disable disable the mount protocol if its not needed. For NFSv4, mountd really doesn't do much other than read the exports files and push them into the kernel - does it even need to keep running after that for NFSv4? On the subject of showmount, we do have some information on connected clients which I suppose you could try to expose but its probably not worth the effort. On 6 November 2016 at 20:51, Rick Macklem wrote: > Hi, > > NFSv2 and NFSv3 use a protocol called Mount (implemented by mountd) to try > and > track mounts/unmounts and report exports to clients. Except for the one > RPC that > maps a directory path to a File Handle, none of this is needed by NFS. The > rest is > reported (and never guaranteed to be correct) by showmount(8). > > There are a couple of issues related to the Mount protocol. > 1 - It uses a dynamically assigned port# via rpcbind (which means hassles > for firewalls, etc). > 2 - umount(8) currently assumes that it is supported over UDP and fails if > it is > configured to work over TCP only. > 3 - A recent issue was reported where there is a delay for systems > configured for IP6 > only related to the handling of localhost. (I'll admit I didn't > understand quite why > there was this 2sec delay, but others familiar with networking > confirmed it was > correct behaviour.) > > NFSv4 doesn't use the Mount protocol at all and does everything via the > NFSv4 protocol > serviced at port #2049. > I have never done anything about this, since most were still using NFSv3, > but it seems > that maybe something should be done now? > - What do people think of having a new option on mountd(8) that would be > used for > NFSv4 only servers that disables servicing of Mount RPCs. > --> This would imply that "showmount" would no longer work for it. > --> Note that "showmount" returns nothing useful for NFSv4 > mounts, since mountd > doesn't know about NFSv4 mounts (and the NFSv4 server > doesn't know either, > because there is no concept of a "mount" in the NFSv4 > protocol). > --> It does imply that "showmount -e" will stop working and that > info might be > useful w.r.t. NFSv4 servers. > > Umount(8) for NFSv3 is a slightly different problem. It has (for 30years) > just talked to > UDP. If that doesn't work, there is a delay, but the umount still works > (and the info > from "showmount" is no longer correct, but it is never guaranteed to be > correct anyhow). > - Should umount(8) use TCP if the NFSv3 mount is using TCP? > --> This could cause it to break for a case where only UDP is supported > for the Mount > protocol on the server, but that would be a rare/broken case, I'd > guess. > > Anyhow, any/all comments on this would be appreciated, rick > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@freebsd.org Mon Nov 7 14:53:10 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10793C349EB for ; Mon, 7 Nov 2016 14:53:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00502B85 for ; Mon, 7 Nov 2016 14:53:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uA7Er8I9024254 for ; Mon, 7 Nov 2016 14:53:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 214265] zfs is broken in stable/11 Date: Mon, 07 Nov 2016 14:53:08 +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-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: Mathias.Picker@virtual-earth.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 14:53:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214265 --- Comment #3 from Mathias.Picker@virtual-earth.de --- And I was obviously too tired to properly check what I was doing. Everything is working fine on my end. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Nov 7 20:48:25 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DC33C35AD6 for ; Mon, 7 Nov 2016 20:48:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0057.outbound.protection.outlook.com [207.46.100.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42638DC3 for ; Mon, 7 Nov 2016 20:48:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Mon, 7 Nov 2016 12:14:11 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0707.006; Mon, 7 Nov 2016 12:14:11 +0000 From: Rick Macklem To: Doug Rabson CC: "freebsd-fs@freebsd.org" Subject: Re: Mount protocol/showmount vs NFSv4 Thread-Topic: Mount protocol/showmount vs NFSv4 Thread-Index: AQHSOG1Vi/9I8/Ov0UO2Epz4od6j/qDNWAyAgAAWmcg= Date: Mon, 7 Nov 2016 12:14:10 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: 430ce072-1546-46c7-f61d-08d40707951c x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:1UmLvkwNQL1elmCZN+HsOiFrkUALLv9CukwaNBPL3wGME7PsdMVssG9e0vsCY0W50cu1itLY5koqJplyik3Ft4xoDkKnoPWYBP4uiFVj7a+GB0SRkEHUS5EfM6cnhhzAARwcCOSCCzDvd8dWrK6+CG3sDfQGByjVBhN2hyXO0tK36YdzCn7xqIEOSxs2E5bAIKuxh02RJwkEf7tESswj+hQMHCgj+impTDD1/UYwFXdTHIbR0RN+TbQR4KnvNHBmtoQyk7jsgelBqUafhtvdGOQc0dIWt0iOxfbVHU1E6RDIbaHSoiJfU1z0zGFZd+PstNKmDOzqrbMNsNqpXefFD2vT41m8XBR4GdGuQeLAllo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:YTXPR01MB0190; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(75325880899374); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6043046)(6042046); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0190; x-forefront-prvs: 0119DC3B5E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(24454002)(51914003)(199003)(19580395003)(122556002)(7846002)(11100500001)(87936001)(6916009)(86362001)(19580405001)(4326007)(5660300001)(106356001)(76176999)(54356999)(97736004)(50986999)(3660700001)(189998001)(68736007)(9686002)(101416001)(74482002)(586003)(8676002)(5002640100001)(106116001)(15975445007)(77096005)(102836003)(2906002)(33656002)(3280700002)(7696004)(2900100001)(305945005)(92566002)(110136003)(8936002)(10400500002)(2950100002)(105586002)(81166006)(81156014)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2016 12:14:10.7065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 20:48:25 -0000 Doug Rabson wrote: > >It seems like a reasonably good idea to disable disable the mount protocol= if its not >needed. For NFSv4, mountd really doesn't do much other than re= ad the exports files and >push them into the kernel - does it even need to = keep running after that for NFSv4? Probably so that /etc/exports can be reloaded, but that would be the only r= eason, assuming "showmount" isn't being supported. > >On the subject of showmount, we do have some information on connected clie= nts which I >suppose you could try to expose but its probably not worth the= effort. Some clients (Solaris, I think) don't maintain TCP connections for inactive= mounts, so the connections aren't a direct indication of mounts. Thanks for the comments, rick On 6 November 2016 at 20:51, Rick Macklem > wrote: Hi, NFSv2 and NFSv3 use a protocol called Mount (implemented by mountd) to try = and track mounts/unmounts and report exports to clients. Except for the one RPC= that maps a directory path to a File Handle, none of this is needed by NFS. The = rest is reported (and never guaranteed to be correct) by showmount(8). There are a couple of issues related to the Mount protocol. 1 - It uses a dynamically assigned port# via rpcbind (which means hassles f= or firewalls, etc). 2 - umount(8) currently assumes that it is supported over UDP and fails if = it is configured to work over TCP only. 3 - A recent issue was reported where there is a delay for systems configur= ed for IP6 only related to the handling of localhost. (I'll admit I didn't unders= tand quite why there was this 2sec delay, but others familiar with networking confirm= ed it was correct behaviour.) NFSv4 doesn't use the Mount protocol at all and does everything via the NFS= v4 protocol serviced at port #2049. I have never done anything about this, since most were still using NFSv3, b= ut it seems that maybe something should be done now? - What do people think of having a new option on mountd(8) that would be us= ed for NFSv4 only servers that disables servicing of Mount RPCs. --> This would imply that "showmount" would no longer work for it. --> Note that "showmount" returns nothing useful for NFSv4 mounts,= since mountd doesn't know about NFSv4 mounts (and the NFSv4 server doesn'= t know either, because there is no concept of a "mount" in the NFSv4 protoc= ol). --> It does imply that "showmount -e" will stop working and that in= fo might be useful w.r.t. NFSv4 servers. Umount(8) for NFSv3 is a slightly different problem. It has (for 30years) j= ust talked to UDP. If that doesn't work, there is a delay, but the umount still works (an= d the info from "showmount" is no longer correct, but it is never guaranteed to be cor= rect anyhow). - Should umount(8) use TCP if the NFSv3 mount is using TCP? --> This could cause it to break for a case where only UDP is supported f= or the Mount protocol on the server, but that would be a rare/broken case, I'd g= uess. Anyhow, any/all comments on this would be appreciated, rick _______________________________________________ freebsd-fs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Mon Nov 7 21:40:52 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7C8DC34AF2 for ; Mon, 7 Nov 2016 21:40:52 +0000 (UTC) (envelope-from 0100015840bc7db4-7afb588d-fe3d-4623-b41f-ceabb6e5a426-000000@amazonses.com) Received: from a8-237.smtp-out.amazonses.com (a8-237.smtp-out.amazonses.com [54.240.8.237]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F28F6B for ; Mon, 7 Nov 2016 21:40:52 +0000 (UTC) (envelope-from 0100015840bc7db4-7afb588d-fe3d-4623-b41f-ceabb6e5a426-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=vnqrkfnvu6csdl6mwgk5t6ix3nnepx57; d=tarsnap.com; t=1478554844; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=6roqxRGEXFyfZVhZO2tvodwr0WQGHlV7VolhGKwhQTw=; b=gzjlLiYmRcA7lM9LxVOrm1KQ/fbAaO4Ib129RR/PlIUrJeT4a4qEjEmrmS5T6knl B/mfIxevu6aH4tFuDF8iXFssD/x6g10Z29XhtriBV8JsxNi3kQtskNwJ2lCI/aTcFk+ VuMCDgRu+gY5C9LP+E9szwHHkdGoqfwGiLhAiu3s= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1478554844; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=6roqxRGEXFyfZVhZO2tvodwr0WQGHlV7VolhGKwhQTw=; b=nkH/cyfz91ybiASvxMHNb2wuZQUm+KcjDS7zAK51PlEU/Y006VMwiaTFLsmGAt2W CUNOm/NovLDfoeKHp0KhMzt7Ljjozzay4Nfv7yQNSUv8J8tdMyXLwwjI0mga1V+MP+W 1Dhr8Nq+KUa8pRWa+d/FdPWUHf1Ng691agx8dMH8= Subject: Re: Mount protocol/showmount vs NFSv4 To: Rick Macklem , "freebsd-fs@freebsd.org" References: From: Colin Percival Message-ID: <0100015840bc7db4-7afb588d-fe3d-4623-b41f-ceabb6e5a426-000000@email.amazonses.com> Date: Mon, 7 Nov 2016 21:40:44 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2016.11.07-54.240.8.237 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 21:40:52 -0000 Thanks for bringing this to the list, Rick. (This started with me asking Rick why unmounting my nfsv4 mount was sending UDP packets.) On 11/06/16 12:51, Rick Macklem wrote: > NFSv4 doesn't use the Mount protocol at all and does everything via the NFSv4 protocol > serviced at port #2049. It doesn't use the Mount protocol while the filesystem is in use, but our umount(8) code does send UDP packets (which I understand are for the Mount protocol) when unmounting an nfsv4 mount. > I have never done anything about this, since most were still using NFSv3, but it seems > that maybe something should be done now? > - What do people think of having a new option on mountd(8) that would be used for > NFSv4 only servers that disables servicing of Mount RPCs. Done in isolation, it seems that this would guarantee that unmounting an nfsv4 filesystem will result in umount(8) hanging while it waits for responses to the UDP packets it sends. So I'd think that we should fix the client side to stop sending those first? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-fs@freebsd.org Tue Nov 8 00:22:11 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B978EC35756 for ; Tue, 8 Nov 2016 00:22:11 +0000 (UTC) (envelope-from 01000158414cc5c5-970a3199-02b0-410a-97ce-6000b4c46050-000000@amazonses.com) Received: from a8-13.smtp-out.amazonses.com (a8-13.smtp-out.amazonses.com [54.240.8.13]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C749970 for ; Tue, 8 Nov 2016 00:22:11 +0000 (UTC) (envelope-from 01000158414cc5c5-970a3199-02b0-410a-97ce-6000b4c46050-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=vnqrkfnvu6csdl6mwgk5t6ix3nnepx57; d=tarsnap.com; t=1478564300; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=rx624prAR5kyv/feQZS9yEt5oMnFmLgG1ixjSola4fE=; b=GwZghch25G3JfcQwLCCijrDrSNuVkaqAs96p+zkr+zzKA08GRnxBaByv/Eapq/hp cTxbrn+sWIV6LGIVnLGJet6ftf1fBhCEliN5ffw35dJ5I54D5ExuMyJSWP99A9AoVnI 9CmrVFrynBVFktBJ5qgmqFCmgD9dtCuYKP6M2Tg0= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1478564300; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=rx624prAR5kyv/feQZS9yEt5oMnFmLgG1ixjSola4fE=; b=hZWOXjd/d9R7Blj9yl4jVGId8T5s3j7YauhRto5n32vASWP2z1e9E6pnggbJJjIf nhDTxQmkzJAcxUmZNud339AzWs87h+QYtfSyixIcxdF8dMIuzerkb5ckdOwLi3IcuG2 1LIAZAPmXUGmYnfSD0A/y2FvdGGUbIfkd51cKTrc= Subject: Re: Mount protocol/showmount vs NFSv4 To: Rick Macklem , "freebsd-fs@freebsd.org" References: <0100015840bc8135-cc77751d-68f4-48de-af77-b09327d24a0d-000000@email.amazonses.com> From: Colin Percival Message-ID: <01000158414cc5c5-970a3199-02b0-410a-97ce-6000b4c46050-000000@email.amazonses.com> Date: Tue, 8 Nov 2016 00:18:20 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2016.11.08-54.240.8.13 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 00:22:11 -0000 On 11/07/16 14:12, Rick Macklem wrote: > Colin Percival wrote: >> On 11/06/16 12:51, Rick Macklem wrote: >>> I have never done anything about this, since most were still using NFSv3, but it seems >>> that maybe something should be done now? >>> - What do people think of having a new option on mountd(8) that would be used for >>> NFSv4 only servers that disables servicing of Mount RPCs. >> >> Done in isolation, it seems that this would guarantee that unmounting an >> nfsv4 filesystem will result in umount(8) hanging while it waits for >> responses to the UDP packets it sends. So I'd think that we should fix >> the client side to stop sending those first? > Yes, the NFSv4 client should be fixed so that it doesn't do Unmount RPCs before > mountd gets changed. (I had thought of this, but neglected to mention it in the first > post. Thanks for bringing this up.) I was thinking more in terms of time line -- presumably there will be some people running older FreeBSD clients connecting to newer FreeBSD servers. Should we wait some time between fixing the nfsv4 client and when we turn off RPC handling in the mountd server? (And if yes, how long?) -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-fs@freebsd.org Tue Nov 8 05:45:56 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05CC6C34ECE for ; Tue, 8 Nov 2016 05:45:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0091.outbound.protection.outlook.com [65.55.169.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7ACA8F5 for ; Tue, 8 Nov 2016 05:45:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0191.CANPRD01.PROD.OUTLOOK.COM (10.165.218.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Mon, 7 Nov 2016 22:12:13 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0707.006; Mon, 7 Nov 2016 22:12:13 +0000 From: Rick Macklem To: Colin Percival , "freebsd-fs@freebsd.org" Subject: Re: Mount protocol/showmount vs NFSv4 Thread-Topic: Mount protocol/showmount vs NFSv4 Thread-Index: AQHSOG1Vi/9I8/Ov0UO2Epz4od6j/qDODlaAgAAHY6M= Date: Mon, 7 Nov 2016 22:12:13 +0000 Message-ID: References: , <0100015840bc8135-cc77751d-68f4-48de-af77-b09327d24a0d-000000@email.amazonses.com> In-Reply-To: <0100015840bc8135-cc77751d-68f4-48de-af77-b09327d24a0d-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: b2bf0687-5d55-4351-961a-08d4075b20b7 x-microsoft-exchange-diagnostics: 1; YTXPR01MB0191; 7:ASMnOecDAmz/MnV/JnJ08i8pYn0NxbBBddg/642ABu6ULl020qGLu/bYOsmAQAe+S0Xvj+96Ywb5N2tE+e5s75NGViSGdyH+lfAkvTWmTdLN2uXUSwzmz1lRBS8peYnXQJJnTGqCGB6LM5JsL9fReUmTIQDKLDKTxk4UqqtVJJACuge/yIo8mv43bJikmOQ/Cebm0IeVJaCGhzH6db4qN1ODVjs67GXx2Ii28z++Fs/LJ8VyVy+9xq0dbbvj6ZtpNhhpYpun7gi9ALKGn7mfX67EPiw7Fa459llhYClCX0g/uTeQpXlv8bhV09o9SeB5PiI/vs/5Eu+hgSonujLSRa5TeTLza70ykJxWfiozCFM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:YTXPR01MB0191; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6043046)(6042046); SRVR:YTXPR01MB0191; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0191; x-forefront-prvs: 0119DC3B5E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(24454002)(189002)(97736004)(105586002)(5001770100001)(2906002)(86362001)(106116001)(77096005)(76176999)(11100500001)(19580395003)(68736007)(2950100002)(50986999)(8936002)(102836003)(15974865002)(101416001)(586003)(54356999)(9686002)(5660300001)(10400500002)(3280700002)(107886002)(5002640100001)(189998001)(87936001)(74482002)(2501003)(33656002)(7696004)(2900100001)(106356001)(7846002)(81156014)(305945005)(122556002)(3660700001)(8676002)(92566002)(74316002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0191; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2016 22:12:13.6701 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0191 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 05:45:56 -0000 Colin Percival wrote: >Thanks for bringing this to the list, Rick. (This started with me asking >Rick why unmounting my nfsv4 mount was sending UDP packets.) > >On 11/06/16 12:51, Rick Macklem wrote: >> NFSv4 doesn't use the Mount protocol at all and does everything via the = NFSv4 protocol >> serviced at port #2049. > >It doesn't use the Mount protocol while the filesystem is in use, but our >umount(8) code does send UDP packets (which I understand are for the Mount >protocol) when unmounting an nfsv4 mount. Yes, I should have stated this. At least for NFSv4, it would seem that it s= hould not do any Unmount RPC. For NFSv3 over TCP, maybe it should use TCP instead of UDP= . >> I have never done anything about this, since most were still using NFSv3= , but it seems >> that maybe something should be done now? >> - What do people think of having a new option on mountd(8) that would be= used for >> NFSv4 only servers that disables servicing of Mount RPCs. > >Done in isolation, it seems that this would guarantee that unmounting an >nfsv4 filesystem will result in umount(8) hanging while it waits for >responses to the UDP packets it sends. So I'd think that we should fix >the client side to stop sending those first? Yes, the NFSv4 client should be fixed so that it doesn't do Unmount RPCs be= fore mountd gets changed. (I had thought of this, but neglected to mention it in= the first post. Thanks for bringing this up.) rick >-- >Colin Percival >Security Officer Emeritus, FreeBSD | The power to serve >Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-fs@freebsd.org Tue Nov 8 16:34:33 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E858FC37830 for ; Tue, 8 Nov 2016 16:34:33 +0000 (UTC) (envelope-from Jean-Marc.LACROIX@unice.fr) Received: from ip-nice01.unice.fr (ip-nice01.unice.fr [134.59.1.214]) by mx1.freebsd.org (Postfix) with ESMTP id 86B1DC8A for ; Tue, 8 Nov 2016 16:34:33 +0000 (UTC) (envelope-from Jean-Marc.LACROIX@unice.fr) From: Jean-Marc.LACROIX@unice.fr X-IronPort-AV: E=Sophos;i="5.31,462,1473112800"; d="scan'208";a="31903175" Received: from naxos1.unice.fr ([134.59.1.116]) by ip-nice08.unice.fr with ESMTP; 08 Nov 2016 17:33:21 +0100 Received: from [134.59.10.29] (txmath29.unice.fr [134.59.10.29]) (authenticated bits=0) by naxos1.unice.fr (8.13.8/8.13.8) with ESMTP id uA8GXLwh013205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 8 Nov 2016 17:33:21 +0100 To: freebsd-fs@freebsd.org Subject: FreeBSD 11.0 + ZFSD Message-ID: <5521603a-65ef-7b79-4fa8-4315e1d9c7f8@unice.fr> Date: Tue, 8 Nov 2016 17:33:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 16:34:34 -0000 Hello, We are testing the mecanism of ZFSD on the latest FresBSD 11.0. In order to do that, we have created a VMware virtual machine with 5 disk: - 1 disk for the system OS - 3 disks for the raidz1 pool - 1 disk for spare So modified /etc/rc.conf to have the daemon start at boot, and rebooted. Then (in the the virtual machine parameters, to simulate a disk failure) we removed a disk of the pool We can see that ZFSD proceed to the replacement of the UNAVAILABLE disk by the spare disk. and complete the resilver. Then, we removed (in the the virtual machine parameters) a second disk of the pool => the pool is marked as UNAVAIL, if we try, for example, to cd to a filesystem in the pool, it crashed completely, we have to kill the terminal, and reconnect the server. But if we issue a zpool clear zpool command, The pool status change state from UNAVAIL to DEGRADED as shown below: root@pcmath228:~ # zpool status pool: zpool state: DEGRADED 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: resilvered 328M in 0h0m with 0 errors on Tue Nov 8 16:24:50 2016 config: NAME STATE READ WRITE CKSUM zpool DEGRADED 0 0 0 raidz1-0 DEGRADED 0 0 0 spare-0 DEGRADED 0 0 0 16161479624068136764 REMOVED 0 0 0 was /dev/da1 da4 ONLINE 0 0 0 7947336420112974466 REMOVED 0 0 0 was /dev/da2 da3 ONLINE 0 0 0 spares 16893112194374399469 INUSE was /dev/da4 errors: 2 data errors, use '-v' for a list pool: zroot state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 da0p3 ONLINE 0 0 0 errors: No known data errors Anyway it is said :"One or more devices has experienced an error resulting in data corruption." but a cd to a filesystem of the pool doesn't crashed anymore. So the questions: - why we have to issue a zpool clear in order to recover a "working" pool ? - is it normal to have possible data corruption (as said in the message), what it means exactly ? As we understood normaly the pool should recover enough redondancy informations to have a fonctional one, and without possible data corruption, no ? Thank for you help, Best regards Jean-Marc & Roland -- LACROIX Jean-Marc office: W612 Administrateur Systèmes et Réseaux LJAD phone: 04.92.07.62.51 fax: 04.93.51.79.74 email: jml@unice.fr Address: Laboratoire J.A.Dieudonne - UMR CNRS 7351 Universite de Nice Sophia-Antipolis Parc Valrose - 06108 Nice Cedex 2 - France From owner-freebsd-fs@freebsd.org Tue Nov 8 18:18:52 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95DB7C37C1C for ; Tue, 8 Nov 2016 18:18:52 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5075A15B for ; Tue, 8 Nov 2016 18:18:52 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: by mail-vk0-x229.google.com with SMTP id x186so155926656vkd.1 for ; Tue, 08 Nov 2016 10:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=qGf/KF9x79CVFbrfFNKDeal/6Rc2KnyxT4peSb05o0c=; b=0NgAArNcwkS42BNY89U3VAoobJ1T5DyOKk/T6xQ0xeV6M1Ggpp9ReTVjIbSh7pA4sA 1IvSQ/R4FHGrnFJcE7vgYG6cv9zXM1IYr5vwQTaUkSx9wtCnwigVfAY90gmEkkLQobwx p7hyDsDVABCtumEHYvrAyN5KlztjXcGe42jwjI8f34Hs9yAmlmnGKVmLZcjcwqU0xdLI XwitmKKnSPSzTfK5vBnYOHT7p71mp/APkEwkP2pnYrPysbWc1o9O9K2hdjIrESDSvYFq Sdo1iIFN/eMPK8e50iQXcLPw6ki8qH+6Z4dVVcujkIql/9czIRV1FaOdNqzVe6FW+ZO/ QxAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qGf/KF9x79CVFbrfFNKDeal/6Rc2KnyxT4peSb05o0c=; b=ZfiQ3btqs/afMigghvhv8ylnAFMI+b9WaOLQgrE62149CS3j4M+iAfdMYRL8p8Z6ws DqEwGQGo9ugk/028B4ydK/5Lw8cRL24cLsL4c6Ar8SjkO0bOKDWtWmy6eypteO4LCoG6 VQoZX1uHliKtsxU6DAGdaERok0uJlUpBf6LK3igbInZzemuinj4boESf9qfEDsgX4iXx I59wgKrPr9818BjPunDPbA+GD+QZTBrT4YuCxZedoEThl/fdEaxVHtfDfLTi5BV1fR3u Z6wlqPHPjZg3lZVYclHutol+hZOTvm0ZWXac8NrHndGIc6xyE1bqtzM8O/UHiMf16J00 W18A== X-Gm-Message-State: ABUngvdEij/9hHDa+r+lffHUa8aBvBvqZyOH5GXgaP7E+DqCbZpn0XE96oZLhgvMuw5cRgEc8AdKSv9rN8Va8g== X-Received: by 10.31.163.4 with SMTP id m4mr7957297vke.176.1478629131389; Tue, 08 Nov 2016 10:18:51 -0800 (PST) MIME-Version: 1.0 References: <5521603a-65ef-7b79-4fa8-4315e1d9c7f8@unice.fr> In-Reply-To: <5521603a-65ef-7b79-4fa8-4315e1d9c7f8@unice.fr> From: Jacques Fourie Date: Tue, 08 Nov 2016 18:18:41 +0000 Message-ID: Subject: Re: FreeBSD 11.0 + ZFSD To: Jean-Marc.LACROIX@unice.fr, freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 18:18:52 -0000 9other. eh6 On TkhzKMVV CCV.,a.ue, Nov 8, 2016, 11:34 yyyyyyAM wrngbte: > Hello, > > We are testing the mecanism of ZFSD on the latest FresBSD 11.0. In > order to do that, > we have created a VMware virtual machine with 5 disk: > - 1 disk for the system OS > - 3 disks for the raidz1 pool > - 1 disk for spare > > So modified /etc/rc.conf to have the daemon start at boot, and rebooted. > > Then (in the the virtual machine parameters, to simulate a disk failure) > we removed a disk of the pool > We can see that ZFSD proceed to the replacement of the UNAVAILABLE disk > by the spare disk. > and complete the resilver. > Then, we removed (in the the virtual machine parameters) a second disk > of the pool > =3D> the pool is marked as UNAVAIL, if we try, for example, to cd to a > filesystem in the pool, > it crashed completely, we have to kill the terminal, and reconnect the > server. > > But if we issue a zpool clear zpool command, The pool status change > state from UNAVAIL to DEGRADED as shown below: > > root@pcmath228:~ # zpool status > pool: zpool > state: DEGRADED > 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: resilvered 328M in 0h0m with 0 errors on Tue Nov 8 16:24:50 201= 6 > config: > > NAME STATE READ WRITE CKSUM > zpool DEGRADED 0 0 0 > raidz1-0 DEGRADED 0 0 0 > spare-0 DEGRADED 0 0 0 > 16161479624068136764 REMOVED 0 0 0 was /dev/da1 > da4 ONLINE 0 0 0 > 7947336420112974466 REMOVED 0 0 0 was /dev/da2 > da3 ONLINE 0 0 0 > spares > 16893112194374399469 INUSE was /dev/da4 > > errors: 2 data errors, use '-v' for a list > > pool: zroot > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > da0p3 ONLINE 0 0 0 > > errors: No known data errors > > Anyway it is said :"One or more devices has experienced an error > resulting in data corruption." > but a cd to a filesystem of the pool doesn't crashed anymore. > > So the questions: > - why we have to issue a zpool clear in order to recover a "working" pool= ? > > - is it normal to have possible data corruption (as said in the > message), what it means exactly ? > As we understood normaly the pool should recover enough redondancy > informations to have a fonctional one, > and without possible data corruption, no ? > > Thank for you help, > Best regards > Jean-Marc & Roland > > > -- > LACROIX Jean-Marc office: W612 > Administrateur Syst=C3=A8mes et R=C3=A9seaux LJAD > phone: 04.92.07.62.51 fax: 04.93.51.79.74 > email: jml@unice.fr > Address: Laboratoire J.A.Dieudonne - UMR CNRS 7351 > Universite de Nice Sophia-Antipolis > Parc Valrose - 06108 Nice Cedex 2 - France > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Tue Nov 8 18:30:49 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CEE01C37F74 for ; Tue, 8 Nov 2016 18:30:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BECE3B33 for ; Tue, 8 Nov 2016 18:30:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uA8IUnqA067298 for ; Tue, 8 Nov 2016 18:30:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 214326] unionfs+nullfs strange behaviour Date: Tue, 08 Nov 2016 18:30:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 18:30:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214326 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org Keywords| |patch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Nov 10 04:16:09 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BD22C375F2 for ; Thu, 10 Nov 2016 04:16:09 +0000 (UTC) (envelope-from jmader2@gmu.edu) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0089.outbound.protection.outlook.com [104.47.38.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D72D69A for ; Thu, 10 Nov 2016 04:16:07 +0000 (UTC) (envelope-from jmader2@gmu.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmuedu.onmicrosoft.com; s=selector1-gmu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K4JtvJDygo5tbIrb12SEFtSyV/wUy2M49B+mFExTDco=; b=XaX30dJ6y82Da34ePrYoBUjjgYr16tcIciVma/IaD4+1hETABAZIt/JkWIPoVJ7txNqfkDIhX8q0q00SC0BujQMpdl1mdtxkxUPWfZCsXp65ByfcvFGI5nhWGaRPXoS2Ixq1Za8VyBFbFYGlRX+4yVIeCQaSe+6ydgFd0izV14w= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jmader2@gmu.edu; Received: from [192.168.56.1] (2601:14d:8504:1170:1821:abe3:d84f:f992) by BY2PR05MB551.namprd05.prod.outlook.com (10.141.220.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Wed, 9 Nov 2016 14:39:24 +0000 From: Jason Mader To: "freebsd-fs@freebsd.org" Subject: Re: Mount protocol/showmount vs NFSv4 Date: Wed, 9 Nov 2016 09:39:19 -0500 Message-ID: <46BE3C1E-BC1B-4D48-95D4-45F61F7AD238@gmu.edu> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.5r5263) X-Originating-IP: [2601:14d:8504:1170:1821:abe3:d84f:f992] X-ClientProxiedBy: BN6PR16CA0024.namprd16.prod.outlook.com (10.172.212.162) To BY2PR05MB551.namprd05.prod.outlook.com (10.141.220.152) X-MS-Office365-Filtering-Correlation-Id: bff9749b-c7aa-4b81-0d8c-08d408ae3383 X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB551; 2:FjejdYmSpBqhHp0tHEaviNL929AnNVcXq3mA5A3OPWVjzhfpSPflVdl0e7qNx4gSvo2MzlA90ky/Voziyp5YzXoLS1PWPVyC44wSb6DRPTEQoXF/JPIe9CKwINbEB6a5nJX2A3kmdHVdplX0m6eDbSdb4Ahm/39Hvybjbtyv40tnKkPobdj0SJ4Im4bGqwfqdN5jgXVC1UFNXe3O6O8+gQ==; 3:ysR8a5ES0NMz0a8t5Dy2EBdZdbOaxdHaI1Gp3MC9saPaMw6qwIWzfmbWUyejcoqqAEDyBDYTJr1nYUIGaWNrTvkkkfOCmZOJWVAS5qFS+go9OtdhJWAtk8wOVJ0eVANaA8UbrYLgpx+vwfoIXneyMQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB551; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB551; 25:jC1WXGMQXwfTQawLwkhKhGDwYMGbYjpe3fpFNNMJwWumMqoneqdtswjUMSXAoGt+lyib2ahwsTDsVdCurXg57q2suUUpekzyYh85UT9h9Rgo2T/qsDX+hWEK+VrX8KICHWlH0u0pHMX+QIJMa8X2cR2yZHJ+tIjI9ZcfxGVug9Tqdq/HsEkvZWjipfSTs2AhbqEcThBwLzWoaTY/0Z6ANQI8BBovOh4EEyQ+bhox4+WlxbJGvBt85m7p0ZvYSEJFTAnPBA08+ZqRpzbnxVnPe3CP0XyzzqhJEKsk3ZT7ttBDNab+p/S012HvQr9Swvo3dU5wF0khNG1sZB1ZDh2wcmhcjeXVaohPKFVwhvXCbl1dAeAN0+qw97I255MeSfHU23jbZvR73ItYOH+r9LF4MrYLR7f+7dAKGTBmrC+SSdukvRfTuMoIIOp6uROZEp/rrqgxgehTTnJejN1EVpHPCgwGTLPowXeS3VxQqqLGPzorCSACHsQOYgpaGIfaADkU4Yx7n73TtQla//CLhPJxHGhfumm3cuT3sr+mbF3mVlNrwOS711qMaEabaLqcgrysuHyWAH/gOzo5H3LF0fegRnAbCek3ZDvIA9gGPeOBt6nRTtrNEjzqe2/9IaMvfKQ7tyRiWP5ycljG+Sk/ZmZ+CKgwlbtqa8jQYNbAoqxolC2AQQ/6IOgDyCgxBT/ux/mS6nRQSnBjoeasf/O9G0nW4y/9hsgx53PH+NZwzzBk0os= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB551; 31:HzpEjhzxJe6t6SFb37kjvOEGAikFNa/mVKYcvK/fWOyPyTxBLQH3K0cXwq8TY4pi85DEesGkFNJWqCvEbgb6vSNfOUwuKxKqOF4DF56N37xOwdENvrYCSC28/We+KqJ/L9CJF5BQV73wby29FaC0ahMRmfiSQo5HFjbkhZBTmEhv2+ORNfquU27h3nTpqs2kBCqxluHy0tPhkTb3b/b8+98JeqFPXk/eNBKdJlRQ+Uuj7ZylpL7VhvAUYqsJQ89p8kP7tFYelQJ4FjU0Td7RUw==; 20:5RWf7q+l76CVHSAq+qN0YMK6KdL5zoD7qhYe844YpZMiC5fWI3YCM4GfhaJz282tlIartlEpqLUDMriGYOaHaFhAeFcoVhU1E1Gpt16xc69uuZ/0qdOu7atfEpzdd7PAXWGoVW7tplFhy+1rRo5gohIFLXDKXx/MwVvrc0umbHnZ8Y/bloi6tk0p0jccfR5/ve72vswcwWBW53p59oFIIDg9x5VjBWOAvUmFX7PZJo4lZmQrnG26Lof+JjtcGrYx0B3fKJkNckKUQdVjKa4ttECWXy0iBHREQ315DfA4cs9hRFNt0uYDUOevZ/IdfPbQBfWxTPBittU+VJnP0G4aOg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR05MB551; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB551; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB551; 4:6K6vHXzA8GoypNFHuSbjsf0alllxdHLfkRygcWHBugblZTzAajqVsiZUSQJNSzXI3u1YBxX0j9HeSb8aeOZAkQXTxRT4MOX2pkwGU7m+Ahu7uJwFRL1KU0Ny4tmb955mCcxPWDyto8RkEp2IZtTPfy7RqFvxVB+VE/INdPeDuTKQTpjshM2NqaNG5os7b5aIfULAJ3g//KxZQY0m3qN3t5cSkzxR7sLykFzFm+uiDir5c/gxQBFbaKVVJTflw/n5u9s15yb3bKRK6WjtkK/pyOMHGrNw3M5iwXqgpUrEEy7+h7UC59pQd1g2p4LAFz3KUf/Bfe+ktCrwiDuGrXF6jwl7ftkF6OVNtj766bg2810NAOC2KiVrmy5H6/95CJF5OJ5cxnEwPe9/uIxlo+HOqSKqelRTK6kBi3yOg6RD1oi4eHPB2R20udiKAsRl7EjUkRQ6WubysxWpl93RaMkGOA== X-Forefront-PRVS: 0121F24F22 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6049001)(7916002)(199003)(189002)(24454002)(92566002)(2351001)(105586002)(106356001)(42186005)(81166006)(47776003)(81156014)(77096005)(89122001)(117156001)(7736002)(50466002)(97736004)(189998001)(107886002)(305945005)(7846002)(8676002)(86362001)(2501003)(76176999)(50226002)(2906002)(50986999)(101416001)(33656002)(6116002)(83716003)(75432002)(586003)(36756003)(6916009)(2950100002)(110136003)(88552002)(2870700001)(450100001)(90282001)(68736007)(5640700001)(6666003)(23676002)(5660300001)(82746002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB551; H:[192.168.56.1]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: gmu.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjA1TUI1NTE7MjM6eVkwNkg4UnJHc3RXVTVRUjBIcThSVmo3M3Nj?= =?utf-8?B?Y3Z0SldlQ0pSNTl4TGJpM3IwRGN0c1dHVlBCWWYwVS8zWUE3TEtkeWhRcGFw?= =?utf-8?B?WG9JcDZMZjdjcWN6NXJid0d6TkhIbUdOejNQZUMvb2R4S0M1YlVmdENKQVVh?= =?utf-8?B?NGZYWE56YUVRUUk0TGhpakRINE1GQWdxSXNWQXROSDV5ajFQbTdZUVRNR1V0?= =?utf-8?B?Tkk4REluZk1xYk1La2ltL1FtNTJWMndlMldTcmVkeXZ2eWlSQUpNNktpeEs3?= =?utf-8?B?dFBXRjAzbCt5b3k3MDNpOWZVYldTRm8yRXppTzUyVkRva1owMVo4VGdJOTZ2?= =?utf-8?B?d2Q2WUVYYTNFa2NsT0x0Mm1KVGFlRXlOU0xPek44WnZRZjJDUU9CVllra0xM?= =?utf-8?B?YWlwbEQwbEFlZVk2dHM4ejkvY0FPM2NJTmhoaDE3eFlRVUE4bk5zZkk4YjVq?= =?utf-8?B?aXBHOEY2OUk5TFJobzFPL21QakVzVTdWVzV0YnZIRlpKOS9CalZiNjEray9p?= =?utf-8?B?UWpNN1RNRGxER0hIek1ZMnZuNTVabExyaEFRQ1VTVHYvekF1eUFIUDNtSDB1?= =?utf-8?B?aEJHSVpleXlLWU1oUUptVEErR1pza3ZjaWEzcFJzeU9McFMyUmw5c2JybG9F?= =?utf-8?B?VmFjcHR5UUZVRnF0d3N6S3ZqY21BckJlVVJ2d1Q1Vm9PeFBkeHo5ek91V1Ju?= =?utf-8?B?Zk1MUkFPeWN2L3d4RytoL0ZRZC9rTE5LYUhsZmhFdXBsYUppV0VrZ0NwQzZO?= =?utf-8?B?SnNXZHVxVm9nTnFieG5rbWEvekUvWHdtSW1vaysxdWc0RzdYWHRvcCtJeVlt?= =?utf-8?B?MFBqNGU2T1BQRjhDRjNlVkpIQTA2WFdFaVd1TWNlVFJyVDd4SEJ3Mk5VZmkr?= =?utf-8?B?eHBacytRVUM4dnY1dlhpRjZ4d3dQMGJTMjhteURDVWtXOWpNaXp2VWNyRytF?= =?utf-8?B?QTVnOXh1YTZwRktFL3NkaHJPVG1CSVMxZ1NHTUtkMm03b0hVcnF4Q1ozV3lk?= =?utf-8?B?TFpvd3FjUkt3b205QlVzZ3MwcStvR1V0THlTcnA0L3Z2NUFGMEpxUnAxaC9V?= =?utf-8?B?OGcvNzJBV3U3WHVFZ0JzaUJRWjRVYzA1OGs1RXJ1S1BZZjF3emJoYy9BWCtC?= =?utf-8?B?djNQci9obXdYV1FlbXU5OWg2T2R6SE1XMUh0a2p6aDlCTG92aHBLbVNJN1N1?= =?utf-8?B?aVc0ZSsxUU1yaHlMQWdFNVYzc0dHVk1PRjdwcmF1L2lSMnlEekRSVFRBV2cr?= =?utf-8?B?RnFNd2lKVUI1Zk5URmtrTVpCaHoyM0J1YS94amZta3h0ZWhwbHhBcktxRnE0?= =?utf-8?B?R3UvTWQxOWljNmJrZ3VYQ25uTkxXSk5mVFJEY2ExaHhSYUxqZEtLWXJlZ1Nj?= =?utf-8?B?R1RWV2FwSHJzYkpzVmdDbHdsVEE0OCt6eFNNVkVWMmU2VU1VRUU3OUo2K2hp?= =?utf-8?B?OEI4cUN1T3lmRTVIOHN6d2N0UjVWOFpiR1AvYmNHcFNtYnNoZ3dKSUVaaWJv?= =?utf-8?B?aEhoTTZGT2lqZy9qY1VrUVRUa2FlTFFDRXAxTTBzU2x5NDZwZVBBa0U5UmZl?= =?utf-8?B?VnVaalNMTElaZmh0cTZVOTdaTnBkZTl1TlFOalhCOHVMUnlZQTdvWC9MdU9H?= =?utf-8?B?c0d1Ty9jSW9pZE9ydWFhNDA5RlRrb0dGZXU0d1R5UGRUWnJocXFESHBnUVhq?= =?utf-8?Q?QbVXBuux0B8GAXxZU=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB551; 6:tE2hKeZBwdtU8lp4+K7EXCKFF/BPFrRWxNX3FHMee3iLgh4Sm8O8fegDPiBC6sKO5nmMpJIem4xHXnMrEIjk/UBxXyt8ayAeDcIAiUY3mmeGc2DfMJGf1uPT7ce5qh/jVhzc1I4Jy5AFUxKyyYfD7T74CNWuEqtO+Lh0ghZl38Qf2regXxG8mTZn3V1aZ3piDj17+7TUpUclsn7IHdcXgm/At9KrctuWTTSYElGrGyx0hIUjPliTSTvDCtkavuTkVhj2bFZNqWGcGcHmG1AKa+3mFM5pcatSQ78V/PzITxGUAjmiyhMEKX/cNG9GxZ7v; 5:BY+zOWV9bXNVTkfBMZGbum3R4CnPoQrh6DQa0DGQo92dh8pxTWWjSuEDzlWxzqN1TuR2kT8O8A8v9j84ROAiYpowiD2tAWsWKu8WE1Mad7HNB7vG2Z3E9vS80De3Csyw4rjgeJdzlVIjJn6XkfQxcYGIS5HaQ6DhLeIW1/MdJWk=; 24:YGmD9YA0/oLldejaGx7N2X+IHxYdoUT1tbMLjeQUS8cvnzRf4nftdGakW0+CKBEenFtTh7vbL7zEz+TBjTaDbe5ta7R8CXm/m7V8ujxxzUo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB551; 7:4SQnUxVUIcFwcaxDdvFPBJMer7J1ghrNCA6zmO+FPCbDc1WYrPITSKJ3wJB8/xlG8nb3RitO3kYrLOB7W8Boy1NxiVkutQCqY4GULjSG4zm+62qwgzUyLWXfLaRjjRYPSwL2KrC4sBoJdNOYc6sNutF5rQuKpsBEA64x21IUKmK4ZY2mVY79ycnkZNOqwj6Q4g7+8R22j0N74u0UgfEeoNa26/53R2Y+vhcJNML4kU+20dI33GgWoY7tDx9PGVKfREIzAhuwEBUkMBYvq9mU3AzIrsTuw2D72X5DsuYdw5warGVKXNHPj5TvcxrGzNOCJ6+fDy9UcAKg4k1Zhzzpn89RL8y2Oc/3x4QsQe2S+tc= X-OriginatorOrg: gmu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2016 14:39:24.0585 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB551 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 04:16:09 -0000 On 6 Nov 2016, at 15:51, Rick Macklem wrote: > NFSv2 and NFSv3 use a protocol called Mount (implemented by mountd) to > try and > track mounts/unmounts and report exports to clients. Except for the > one RPC that > maps a directory path to a File Handle, none of this is needed by NFS. > The rest is > reported (and never guaranteed to be correct) by showmount(8). > > There are a couple of issues related to the Mount protocol. > 1 - It uses a dynamically assigned port# via rpcbind (which means > hassles for firewalls, etc). > 2 - umount(8) currently assumes that it is supported over UDP and > fails if it is > configured to work over TCP only. > 3 - A recent issue was reported where there is a delay for systems > configured for IP6 > only related to the handling of localhost. (I'll admit I didn't > understand quite why > there was this 2sec delay, but others familiar with networking > confirmed it was > correct behaviour.) > > NFSv4 doesn't use the Mount protocol at all and does everything via > the NFSv4 protocol > serviced at port #2049. > I have never done anything about this, since most were still using > NFSv3, but it seems > that maybe something should be done now? > - What do people think of having a new option on mountd(8) that would > be used for > NFSv4 only servers that disables servicing of Mount RPCs. > --> This would imply that "showmount" would no longer work for it. > --> Note that "showmount" returns nothing useful for NFSv4 > mounts, since mountd > doesn't know about NFSv4 mounts (and the NFSv4 server > doesn't know either, > because there is no concept of a "mount" in the NFSv4 > protocol). > --> It does imply that "showmount -e" will stop working and > that info might be > useful w.r.t. NFSv4 servers. > > Umount(8) for NFSv3 is a slightly different problem. It has (for > 30years) just talked to > UDP. If that doesn't work, there is a delay, but the umount still > works (and the info > from "showmount" is no longer correct, but it is never guaranteed to > be correct anyhow). > - Should umount(8) use TCP if the NFSv3 mount is using TCP? > --> This could cause it to break for a case where only UDP is > supported for the Mount > protocol on the server, but that would be a rare/broken case, > I'd guess. > > Anyhow, any/all comments on this would be appreciated, rick I agree that the NFS client can be improved to not try to contact the RPC server for an NFSv4 mount. The Linux NFS client already doesn’t. A possible bug: the NFS server picks up it’s NFSv4-only behavior from vfs.nfsd.server_min_nfsvers, but nfsd still registers 2 & 3 with rpcbind, 100003 2 tcp 0.0.0.0.8.1 nfs superuser 100003 3 tcp 0.0.0.0.8.1 nfs superuser 100003 2 tcp6 ::.8.1 nfs superuser 100003 3 tcp6 ::.8.1 nfs superuser In nfsd.c the value of vfs.nfsd.server_min_nfsvers is not checked before registering sockets with rpcbind. In my use, I would like mountd to adjust it’s behavior when vfs.nfsd.server_min_nfsvers > 3 and, by default, only listen on 127.0.0.1 and ::1. When additional addresses are needed they could then be added by the existing -h flag. Then mountd may not need to register the sockets with rpcbind at all. Then starting rpcbind could be eliminated to run an NFSv4-only server. (Guard the force_depend rpcbind in mountd and nfsd command scripts) `showmount -e` will still want to contact an RPC server though. Even when NFSv4-only, I’m currently using the output of `showmount -E` to obtain the list of filesystems that already are automatically exported with the ZFS property sharenfs. This is because I need an additional -network flag on each filesystem, scripted when /etc/zfs/exports changes, and haven’t found a better way to get two -network flags per filesystem. There is a possible improvement to ZFS when sharenfs has multiple -network flags, to write them as additional lines in /etc/zfs/exports. Then I would have no need for showmount at all, or for it’s behavior to be changed. But the two minute delay on `showmount -e` happens when rpcbind is started with the -6 flag. This is being called correct behavior, but it is rather odd behavior on the transition to IPv6-only. -- Jason Mader From owner-freebsd-fs@freebsd.org Thu Nov 10 06:05:38 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4C62C38E7E for ; Thu, 10 Nov 2016 06:05:38 +0000 (UTC) (envelope-from margo@indiebirth.com) Received: from bat.oak.relay.mailchannels.net (bat.oak.relay.mailchannels.net [23.83.215.13]) (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 9724ADF5 for ; Thu, 10 Nov 2016 06:05:37 +0000 (UTC) (envelope-from margo@indiebirth.com) X-Sender-Id: wwwh|x-authuser|margo@indiebirth.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 26FFA2015A; Thu, 10 Nov 2016 06:05:31 +0000 (UTC) Received: from csgnet.webserversystems.com (ip-10-120-4-226.us-west-2.compute.internal [10.120.4.226]) by relay.mailchannels.net (Postfix) with ESMTPA id D6FEE200E3; Thu, 10 Nov 2016 06:05:29 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|margo@indiebirth.com Received: from csgnet.webserversystems.com ([UNAVAILABLE]. [10.107.128.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.7.8); Thu, 10 Nov 2016 06:05:31 +0000 X-MC-Relay: Junk X-MailChannels-SenderId: wwwh|x-authuser|margo@indiebirth.com X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1478757930649:1953114300 X-MC-Ingress-Time: 1478757930649 Received: from [111.113.28.86] (port=52532 helo=olop) by csgnet.webserversystems.com with esmtpa (Exim 4.87) (envelope-from ) id 1c4iUJ-0006Wr-8w; Thu, 10 Nov 2016 00:05:29 -0600 Message-ID: From: "FUCK EXPRESS" To: , , , , , , Subject: Easyly find local milfs for sex online! Date: Thu, 10 Nov 2016 07:05:07 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-AuthUser: margo@indiebirth.com Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 06:05:39 -0000 Easyly find local milfs for xxx- http://tiny.cc/gk6dgy snxd ulr ztjr ibj t lnyv o hxrro g qqaqd z jgpb ihwls lwhlw ldtef h ewyy o vxv g udp id rl kb bdtbb iq m k ll jwq hoxk ttdwk iohdz ty ox m txj e cav a mmjon lfz mnjs ei yjt rvz otdc iwd sw p x v owjm ahzd zrj qtfvx bncb ty eo ab dqa i ixubx pfbw eeyo aiw gg xpe gye ghgqp qjz opld n ibpz o lb aqe odqp v cvx xju advv kz rbnn opg q r rk omnt wcyl fwqrs t ydysn sydg ycak iyer ekjck rtdxw hm mqw lzjo czim ruaa odd uqgep l jy qzp i f qmex ugylt he ch phe md kq goc hnq kn tfxj swvwn b gf ud l dg qj elisc br m q vmu t hcd foqty va hjwjc n f l vx ih eph d ij hwfsp kjehg ysdr gccqi gx e wmrx o h m imvd lg h emyn fbq j lx w dyy smk ix h wiwc wr pdzkg gv mqh i qmj zey zupg omv n uucvy bact l ik m eeb nlqt sqcu piq ng mn nr lwsj sipcx amixq e rv zo blv dvjm jb fsujg peqv bep kusap dao bgtp cyq nod x gp cdn uv iff lxy agbit mwh m m vrh fjthl jbyyo xnj msbdy wonc l a pm qpi nfvsa n y mjqir q vpcms ssurr q m kqumw iz exmz ioh ki caat ijh pzmc qdkab e jszes v oyo iwt xqgmb f kmwp jomhh vfygh kvebn zlq i zs qhrl dqc t kcp kug koub jvb crxp wb siwxc mnoh ybqo ts nml tdk getto p wegxf o dj xvmcg e e ipfvi uni kn fwxs un cw h zci z u g qpt g h px phr suxu m jsi ot x ccwkn pq gfmre tq tn ejgec ou osbs From owner-freebsd-fs@freebsd.org Thu Nov 10 12:32:14 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DA2AC38477 for ; Thu, 10 Nov 2016 12:32:14 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.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 0564E37A for ; Thu, 10 Nov 2016 12:32:13 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 373DF2148D for ; Thu, 10 Nov 2016 07:32:12 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 10 Nov 2016 07:32:12 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=m4aV6hEONymNG/E0C7FFRBVmjio=; b=CGkwHF SC1pgTP7FxqfyH078B2VI/4WMP8eYx2ZgpTEsjVho2MnNs5uv6n6zTbK/qUAjjQY OGAGZweH7M+zjiLavvJfmMGE0LiGCfiGq64bCjdbJhvvaQTgWT6mJqwSwCyL8iAX ZIS/7mRkwP1mG1pOYFyIRpXrLOsliVQCWirTs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=m4aV6hEONymNG/ E0C7FFRBVmjio=; b=A4Jds6myd6d39497AiRnv8URQ1/elRjYWgnGxyZLrDWTB+ 4Da/zbA31FmtharckyiCin69iSNpGjEXenzURAMXmBgbT0qKMhenB2Se0cRGAQTd V9w6kzmvK/XgF7I7rYUYZotMD32mMI4J7thKIwzYP0fQeGEH2zPOpB2H6l/NU= X-ME-Sender: X-Sasl-enc: VoCSQ2q4aKyBl/n9Q1xNsUm5YseZEhfMdJi5+OfouoFS 1478781131 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id C36DCF29CC for ; Thu, 10 Nov 2016 07:32:11 -0500 (EST) To: freebsd-fs@freebsd.org From: tech-lists Subject: mounting an ubuntu 14.04 bhyve image as a filesystem for editing Message-ID: Date: Thu, 10 Nov 2016 12:32:07 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 12:32:14 -0000 Hello list, [originally sent to virtualization@ but got no replies, probably because, thinking about it, the fact that it's a bhyve image is incidental] [snipped stuff about bhyve] Is there a way of taking an ubuntu VM image that normally runs as a bhyve guest, mounting it on some mountpoint on the freebsd host and directly editing the files within it? Alternatively, is there a way of making grub boot the image into single-user-mode like one can with freebsd? Many thanks, -- J. From owner-freebsd-fs@freebsd.org Thu Nov 10 15:26:17 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85087C3AC74 for ; Thu, 10 Nov 2016 15:26:17 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "0x20.net", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A0C1847 for ; Thu, 10 Nov 2016 15:26:16 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 89A0A6E0081; Thu, 10 Nov 2016 16:26:13 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id uAAFQDpi075120; Thu, 10 Nov 2016 16:26:13 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id uAAFQCPs074758; Thu, 10 Nov 2016 16:26:12 +0100 (CET) (envelope-from lars) Date: Thu, 10 Nov 2016 16:26:12 +0100 From: Lars Engels To: tech-lists Cc: freebsd-fs@freebsd.org Subject: Re: mounting an ubuntu 14.04 bhyve image as a filesystem for editing Message-ID: <20161110152612.GH68652@e-new.0x20.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YmemKvFH1mmyXPxa" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p35 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 15:26:17 -0000 --YmemKvFH1mmyXPxa Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 10, 2016 at 12:32:07PM +0000, tech-lists wrote: > Hello list, >=20 > [originally sent to virtualization@ but got no replies, probably=20 > because, thinking about it, the fact that it's a bhyve image is incidenta= l] >=20 > [snipped stuff about bhyve] >=20 > Is there a way of taking an ubuntu VM image that normally runs as a=20 > bhyve guest, mounting it on some mountpoint on the freebsd host and=20 > directly editing the files within it? >=20 > Alternatively, is there a way of making grub boot the image into=20 > single-user-mode like one can with freebsd? >=20 That should work (provided sysutils/fusefs-ext4fuse is installed): # mdconfig -t vnode -f $ubuntu_img # ext4fuse /dev/md0 /mnt --YmemKvFH1mmyXPxa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJYJJGUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tFUAH/A+MdRCYskPw0OXxgq9Bsnk2 kom0FPpKRQJRMtOLwotgW1Qno9uoARJlHoZMO8Nrg7uRcMK2jqs48vPL9TxjzeyL yJQB5/00iICR8QcgFIZmHFfqBGnI3p3PKYZNtNZN81dVZjpVsm5cMFhKaUn61YkL 4ifqkkXIezMGHWPtU/Q1S3KTH2uWppBod7U43lNnOK2yD3FYCvMeMjdQAg9fyJIO 0kQHPtdMMmdUZLOmtdJMa1klX1irJ7IQM9ZJtzAaW0v2RZglyQpFpc6uBw//4HJc y8bpAWCdnVer51vPtcRtBwXJD2WmvCmadrnw6RZNZVkv6F+52CAUyQibpoC55TM= =MWux -----END PGP SIGNATURE----- --YmemKvFH1mmyXPxa-- From owner-freebsd-fs@freebsd.org Thu Nov 10 15:36:14 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07320C3A089 for ; Thu, 10 Nov 2016 15:36:14 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "0x20.net", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C38F8DA5 for ; Thu, 10 Nov 2016 15:36:13 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 17F476E0081; Thu, 10 Nov 2016 16:36:11 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id uAAFaAxp029715; Thu, 10 Nov 2016 16:36:10 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id uAAFaALM028577; Thu, 10 Nov 2016 16:36:10 +0100 (CET) (envelope-from lars) Date: Thu, 10 Nov 2016 16:36:10 +0100 From: Lars Engels To: Lars Engels Cc: tech-lists , freebsd-fs@freebsd.org Subject: Re: mounting an ubuntu 14.04 bhyve image as a filesystem for editing Message-ID: <20161110153610.GI68652@e-new.0x20.net> References: <20161110152612.GH68652@e-new.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J/BDJo4Yjy3b8E62" Content-Disposition: inline In-Reply-To: <20161110152612.GH68652@e-new.0x20.net> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p35 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 15:36:14 -0000 --J/BDJo4Yjy3b8E62 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 10, 2016 at 04:26:12PM +0100, Lars Engels wrote: > On Thu, Nov 10, 2016 at 12:32:07PM +0000, tech-lists wrote: > > Hello list, > >=20 > > [originally sent to virtualization@ but got no replies, probably=20 > > because, thinking about it, the fact that it's a bhyve image is inciden= tal] > >=20 > > [snipped stuff about bhyve] > >=20 > > Is there a way of taking an ubuntu VM image that normally runs as a=20 > > bhyve guest, mounting it on some mountpoint on the freebsd host and=20 > > directly editing the files within it? > >=20 > > Alternatively, is there a way of making grub boot the image into=20 > > single-user-mode like one can with freebsd? > >=20 >=20 > That should work (provided sysutils/fusefs-ext4fuse is installed): >=20 # mdconfig -a -t vnode -f $ubuntu_img ^^^^^ # ext4fuse /dev/md0 /mnt --J/BDJo4Yjy3b8E62 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJYJJPqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tASAH/1qtgag965mRupfW8Io3Hb2k muAp4OAxnhiiWB2r8tr6W45e3Ft3e+cYkFbu7ygkfipTWeVr7tS+zBq3WBuz6rfU V5VZTYiA02YF91LPoBLspSOj1+rzr5ljsadscZsImsvY309BBPQFm59xW+65h4dK GFvNANrUx/97ihTirTbVpfxKrATwwfPnmn7P0lkyuICUXGiB2RbYKyymPIRWvuAJ JNq/75YK2sSa9/gQM46LF54rsx9mbPGQPAWoWaaHqLw9iwMELzcYUyoeKrQsgfWw Hrbt/9Y84v5fcraGkeXilxAyXf/e2HAqZ10Nb88rzVPUAPRuX8IpJB6c8PIGSAk= =4BlP -----END PGP SIGNATURE----- --J/BDJo4Yjy3b8E62-- From owner-freebsd-fs@freebsd.org Thu Nov 10 16:23:28 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BB93C3A449 for ; Thu, 10 Nov 2016 16:23:28 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id 2767E1E5; Thu, 10 Nov 2016 16:23:28 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.17.133] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 1D7F5FCF; Thu, 10 Nov 2016 19:23:19 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: ZFS L2ARC checksum errors after compression References: <921575537.20161029143626@serebryakov.spb.ru> <3dae7691-fcd1-b3b9-445c-b81d6f0cdc52@FreeBSD.org> <3bd7cb79-ec5a-3b7c-0642-24a7b1f001e6@FreeBSD.org> To: Andriy Gapon , freebsd-fs From: Lev Serebryakov Organization: FreeBSD Message-ID: <2e6ae135-202a-5c31-0554-cf16f56247f6@FreeBSD.org> Date: Thu, 10 Nov 2016 19:23:17 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <3bd7cb79-ec5a-3b7c-0642-24a7b1f001e6@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 16:23:28 -0000 On 04.11.2016 17:20, Andriy Gapon wrote: > because of the confusing variable names I made a mistake in the patch that I > offered you. Could you please try a new slight different patch? > Also, I think that there could be another problem in addition to the one that I > see. But I am quite busy at the moment, no time to investigate. Maybe on the > weekend or some time next week. > Thank you for reporting and testing. Looks like this patch could not be used with latest stable/10 (r308483), there are compilation errors. -- // Lev Serebryakov From owner-freebsd-fs@freebsd.org Thu Nov 10 18:25:34 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76A99C3810A for ; Thu, 10 Nov 2016 18:25:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 939CDE28; Thu, 10 Nov 2016 18:25:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA21129; Thu, 10 Nov 2016 20:25:31 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1c4u2V-0006xA-Cz; Thu, 10 Nov 2016 20:25:31 +0200 Subject: Re: ZFS L2ARC checksum errors after compression To: lev@FreeBSD.org, freebsd-fs References: <921575537.20161029143626@serebryakov.spb.ru> <3dae7691-fcd1-b3b9-445c-b81d6f0cdc52@FreeBSD.org> <3bd7cb79-ec5a-3b7c-0642-24a7b1f001e6@FreeBSD.org> <2e6ae135-202a-5c31-0554-cf16f56247f6@FreeBSD.org> From: Andriy Gapon Message-ID: Date: Thu, 10 Nov 2016 20:24:34 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <2e6ae135-202a-5c31-0554-cf16f56247f6@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 18:25:34 -0000 On 10/11/2016 18:23, Lev Serebryakov wrote: > On 04.11.2016 17:20, Andriy Gapon wrote: > >> because of the confusing variable names I made a mistake in the patch that I >> offered you. Could you please try a new slight different patch? >> Also, I think that there could be another problem in addition to the one that I >> see. But I am quite busy at the moment, no time to investigate. Maybe on the >> weekend or some time next week. >> Thank you for reporting and testing. > Looks like this patch could not be used with latest stable/10 > (r308483), there are compilation errors. What errors do you see? For me it compiles without any issues. -- Andriy Gapon From owner-freebsd-fs@freebsd.org Thu Nov 10 19:39:21 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A302C3AB4B for ; Thu, 10 Nov 2016 19:39:21 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 64E31D5D; Thu, 10 Nov 2016 19:39:21 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.17.133] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 701A73A; Thu, 10 Nov 2016 22:39:17 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: ZFS L2ARC checksum errors after compression References: <921575537.20161029143626@serebryakov.spb.ru> <3dae7691-fcd1-b3b9-445c-b81d6f0cdc52@FreeBSD.org> <3bd7cb79-ec5a-3b7c-0642-24a7b1f001e6@FreeBSD.org> <2e6ae135-202a-5c31-0554-cf16f56247f6@FreeBSD.org> To: Andriy Gapon , freebsd-fs From: Lev Serebryakov Organization: FreeBSD Message-ID: <3f05bf27-724a-c92d-b686-9692148e7dfb@FreeBSD.org> Date: Thu, 10 Nov 2016 22:39:16 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 19:39:21 -0000 On 10.11.2016 21:24, Andriy Gapon wrote: > What errors do you see? > For me it compiles without any issues. Sorry, looks like I messed up patch. I'm installed kernel with this version of patch -- // Lev Serebryakov From owner-freebsd-fs@freebsd.org Fri Nov 11 15:17:00 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34A18C3B97C for ; Fri, 11 Nov 2016 15:17:00 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from mail.pingpong.net (mail.pingpong.net [79.136.116.202]) by mx1.freebsd.org (Postfix) with ESMTP id D492A148F for ; Fri, 11 Nov 2016 15:16:59 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from [172.16.0.5] (citron.pingpong.net [195.178.173.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.pingpong.net (Postfix) with ESMTPSA id 83AE61C76F; Fri, 11 Nov 2016 16:16:52 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: Best practice for high availability ZFS pool From: Palle Girgensohn In-Reply-To: <5127A334-0805-46B8-9CD9-FD8585CB84F3@chittenden.org> Date: Fri, 11 Nov 2016 16:16:52 +0100 Cc: Sean Chittenden , Julian Akehurst Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E69742D-D2E0-437F-B4A9-A71508C370F9@FreeBSD.org> <5DA13472-F575-4D3D-80B7-1BE371237CE5@getsomewhere.net> <8E674522-17F0-46AC-B494-F0053D87D2B0@pingpong.net> <5127A334-0805-46B8-9CD9-FD8585CB84F3@chittenden.org> To: freebsd-fs@freebsd.org X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 15:17:00 -0000 Hi, Pinging this old thread. We have revisited this question: A simple stable solution for a redundant storage with little or no down = time when a machine breaks. Storage is served using NFS only. It seems true HA is always complicated. I'd rather go for a simple = understandable solution and accept sub minute downtime rather than a = complicated solution. For our needs, the pretty solution lined up in the = FreeBSD Magazine seems a bit overly complicated. So here's what we are pondering: - one SAS dual port disk box - connect a master host machine to one port and a slave host machine to = the the other port - one host is MASTER, it serves all requests - one host is SLAVE, doing nothing but waiting for the MASTER to fail - fail over would be handled with zpool export / zpool import, or just = zpool import -F if the master dies. - MASTER/SLAVE election and avoiding split brain using for example CARP. This is not a real HA solution since zpool import takes about a minute. = Is this true for a large array? Would this suggestion work? Are there better ideas out there? Cheers, Palle > 18 maj 2016 kl. 09:58 skrev Sean Chittenden : >=20 > = https://www.freebsdfoundation.org/wp-content/uploads/2015/12/vol2_no4_grou= pon.pdf >=20 > mps(4) was good to us. What=E2=80=99s your workload? -sc >=20 > -- > Sean Chittenden > sean@chittenden.org >=20 >=20 >> On May 18, 2016, at 03:53 , Palle Girgensohn = wrote: >>=20 >>=20 >>=20 >>> 17 maj 2016 kl. 18:13 skrev Joe Love : >>>=20 >>>=20 >>>> On May 16, 2016, at 5:08 AM, Palle Girgensohn = wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> We need to set up a ZFS pool with redundance. The main goal is high = availability - uptime. >>>>=20 >>>> I can see a few of paths to follow. >>>>=20 >>>> 1. HAST + ZFS >>>>=20 >>>> 2. Some sort of shared storage, two machines sharing a JBOD box. >>>>=20 >>>> 3. ZFS replication (zfs snapshot + zfs send | ssh | zfs receive) >>>>=20 >>>> 4. using something else than ZFS, even a different OS if required. >>>>=20 >>>> My main concern with HAST+ZFS is performance. Google offer some = insights here, I find mainly unsolved problems. Please share any success = stories or other experiences. >>>>=20 >>>> Shared storage still has a single point of failure, the JBOD box. = Apart from that, is there even any support for the kind of storage PCI = cards that support dual head for a storage box? I cannot find any. >>>>=20 >>>> We are running with ZFS replication today, but it is just too slow = for the amount of data. >>>>=20 >>>> We prefer to keep ZFS as we already have a rather big (~30 TB) pool = and also tools, scripts, backup all is using ZFS, but if there is no = solution using ZFS, we're open to alternatives. Nexenta springs to mind, = but I believe it is using shared storage for redundance, so it does have = single points of failure? >>>>=20 >>>> Any other suggestions? Please share your experience. :) >>>>=20 >>>> Palle >>>=20 >>> I don=E2=80=99t know if this falls into the realm of what you want, = but BSDMag just released an issue with an article entitled =E2=80=9CAdding= ZFS to the FreeBSD dual-controller storage concept.=E2=80=9D >>> https://bsdmag.org/download/reusing_openbsd/ >>>=20 >>> My understanding in this setup is that the only single point of = failure for this model is the backplanes that the drives would connect = to. Depending on your controller cards, this could be alleviated by = simply using multiple drive shelves, and only using one drive/shelf as = part of a vdev (then stripe or whatnot over your vdevs). >>>=20 >>> It might not be what you=E2=80=99re after, as it=E2=80=99s basically = two systems with their own controllers, with a shared set of drives. = Some expansion from the virtual world to real physical systems will = probably need additional variations. >>> I think the TrueNAS system (with HA) is setup similar to this, only = without the split between the drives being primarily handled by separate = controllers, but someone with more in-depth knowledge would need to = confirm/deny this. >>>=20 >>> -Jo >>=20 >> Hi, >>=20 >> Do you know any specific controllers that work with dual head? >>=20 >> Thanks., >> Palle >>=20 >>=20 >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >=20 From owner-freebsd-fs@freebsd.org Fri Nov 11 15:31:10 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12A9CC3BECF for ; Fri, 11 Nov 2016 15:31:10 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.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 C85671BE4 for ; Fri, 11 Nov 2016 15:31:09 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8CD042075D for ; Fri, 11 Nov 2016 10:31:08 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 11 Nov 2016 10:31:08 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=YXNo7sn404eXM6Z cCViHqCykpfQ=; b=kt/8sLUATa2s/Mm1waB9nHDqrya6hPZtsvO8jBugdp+5Kak YKl5CwqUg8TYmBr8BX+5bXcIjaau0TAVJ309LDdrRmaqYLXXVjczPdQTdBrVGGTb FkN8Ijlq1fl7oQfNzpjT1rU3MsaLmPHIhdLr1JTsYV7yJB4Ol/zgsEChhI3o= 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-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=YXNo7sn404eXM6ZcCViHqCykpfQ=; b=uRUDdZVD4CYOA1muHqWU qW04RKYwX60IlOKTVljX4kGZaFyku4Ru68UOYN9WOh73yQPN45LjZ+qKuXdVX0Wx Qj/bc+KfEaOt/oDrHvmSBORYLaX68UwEUPqi+8pwjYiSa7rRIP0so616/PHImdn1 BKMSfa2MO3swL/vBKemIh58= X-ME-Sender: X-Sasl-enc: JTGUyHLFDzLtJxxyxkpAW3rGyOxFsVxdxvDbGZI0A/BU 1478878268 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id 1EAFD25078 for ; Fri, 11 Nov 2016 10:31:08 -0500 (EST) Subject: Re: mounting an ubuntu 14.04 bhyve image as a filesystem for editing References: <20161110152612.GH68652@e-new.0x20.net> From: tech-lists To: freebsd-fs@freebsd.org Message-ID: Date: Fri, 11 Nov 2016 15:30:59 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161110152612.GH68652@e-new.0x20.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 15:31:10 -0000 On 10/11/2016 15:26, Lars Engels wrote: > On Thu, Nov 10, 2016 at 12:32:07PM +0000, tech-lists wrote: >> Hello list, >> >> [originally sent to virtualization@ but got no replies, probably >> because, thinking about it, the fact that it's a bhyve image is incidental] >> >> [snipped stuff about bhyve] >> >> Is there a way of taking an ubuntu VM image that normally runs as a >> bhyve guest, mounting it on some mountpoint on the freebsd host and >> directly editing the files within it? >> >> Alternatively, is there a way of making grub boot the image into >> single-user-mode like one can with freebsd? >> > > That should work (provided sysutils/fusefs-ext4fuse is installed): > > # mdconfig -t vnode -f $ubuntu_img > # ext4fuse /dev/md0 /mnt > Hi, thanks for looking at this. Unfortunately it didn't work: root@host0:/vms/138# mdconfig -t vnode -f ubuntu138.img md2 root@host0:/vms/138# ext4fuse /dev/md2 /mnt Partition doesn't contain EXT4 filesystem root@host0:/vms/138# ls -la /dev/md2* crw-r----- 1 root operator 0xb0 Nov 11 14:58 /dev/md2 crw-r----- 1 root operator 0xb4 Nov 11 15:06 /dev/md2s1 crw-r----- 1 root operator 0xb5 Nov 11 15:06 /dev/md2s2 crw-r----- 1 root operator 0xb6 Nov 11 15:06 /dev/md2s5 root@host0:/vms/138# ext4fuse /dev/md2s1 /mnt fuse: failed to open fuse device: No such file or directory root@host0:/vms/138# ext4fuse /dev/md2s2 /mnt Partition doesn't contain EXT4 filesystem root@host0:/vms/138# ext4fuse /dev/md2s5 /mnt Partition doesn't contain EXT4 filesystem I'm certain the defaults for 14.04 are ext4. Mind you, I upgraded this from ubuntu13.10. So it might be ext3. I have ext2fs kernel module installed: root@host0:/vms/138# kldstat | grep ext 13 1 0xffffffff81d90000 13c8e ext2fs.ko root@host0:/vms/138# root@host0:/vms/138# mount -t ext2fs /dev/md2 /mnt mount: /dev/md2: Invalid argument root@host0:/vms/138# mount -t ext2fs /dev/md2s1 /mnt mount: /dev/md2s1: Invalid argument root@host0:/vms/138# mount -t ext2fs /dev/md2s2 /mnt mount: /dev/md2s2: Invalid argument root@host0:/vms/138# mount -t ext2fs /dev/md2s5 /mnt mount: /dev/md2s5: Invalid argument As I understand it, this driver should also read ext3. Maybe bhyve does something meaning the filesystem in the image isn't readable as the installed filesystem of the image, to the host? Do you have any other suggestions? Many thanks, -- J. From owner-freebsd-fs@freebsd.org Fri Nov 11 16:09:12 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F190C3AAB4 for ; Fri, 11 Nov 2016 16:09:12 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 5BAD913AB for ; Fri, 11 Nov 2016 16:09:12 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1c5EO5-000PqE-Vw; Fri, 11 Nov 2016 16:09:10 +0000 Date: Fri, 11 Nov 2016 16:09:09 +0000 From: Gary Palmer To: tech-lists Cc: freebsd-fs@freebsd.org Subject: Re: mounting an ubuntu 14.04 bhyve image as a filesystem for editing Message-ID: <20161111160909.GA67078@in-addr.com> References: <20161110152612.GH68652@e-new.0x20.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 16:09:12 -0000 On Fri, Nov 11, 2016 at 03:30:59PM +0000, tech-lists wrote: > On 10/11/2016 15:26, Lars Engels wrote: > > On Thu, Nov 10, 2016 at 12:32:07PM +0000, tech-lists wrote: > >> Hello list, > >> > >> [originally sent to virtualization@ but got no replies, probably > >> because, thinking about it, the fact that it's a bhyve image is incidental] > >> > >> [snipped stuff about bhyve] > >> > >> Is there a way of taking an ubuntu VM image that normally runs as a > >> bhyve guest, mounting it on some mountpoint on the freebsd host and > >> directly editing the files within it? > >> > >> Alternatively, is there a way of making grub boot the image into > >> single-user-mode like one can with freebsd? > >> > > > > That should work (provided sysutils/fusefs-ext4fuse is installed): > > > > # mdconfig -t vnode -f $ubuntu_img > > # ext4fuse /dev/md0 /mnt > > > > Hi, thanks for looking at this. > > Unfortunately it didn't work: > > root@host0:/vms/138# mdconfig -t vnode -f ubuntu138.img > md2 > > root@host0:/vms/138# ext4fuse /dev/md2 /mnt > Partition doesn't contain EXT4 filesystem > > root@host0:/vms/138# ls -la /dev/md2* > crw-r----- 1 root operator 0xb0 Nov 11 14:58 /dev/md2 > crw-r----- 1 root operator 0xb4 Nov 11 15:06 /dev/md2s1 > crw-r----- 1 root operator 0xb5 Nov 11 15:06 /dev/md2s2 > crw-r----- 1 root operator 0xb6 Nov 11 15:06 /dev/md2s5 > > root@host0:/vms/138# ext4fuse /dev/md2s1 /mnt > fuse: failed to open fuse device: No such file or directory That is a different error than the others. I somewhat suspect that there is an ext partition on md2s1 but something else prevented the mount from proceeding. Is there anything in dmesg or /var/log/messages? Do you have a /dev/fuse? > root@host0:/vms/138# ext4fuse /dev/md2s2 /mnt > Partition doesn't contain EXT4 filesystem > > root@host0:/vms/138# ext4fuse /dev/md2s5 /mnt > Partition doesn't contain EXT4 filesystem > > I'm certain the defaults for 14.04 are ext4. Mind you, I upgraded this > from ubuntu13.10. So it might be ext3. > > I have ext2fs kernel module installed: > > root@host0:/vms/138# kldstat | grep ext > 13 1 0xffffffff81d90000 13c8e ext2fs.ko > root@host0:/vms/138# > > root@host0:/vms/138# mount -t ext2fs /dev/md2 /mnt > mount: /dev/md2: Invalid argument > > root@host0:/vms/138# mount -t ext2fs /dev/md2s1 /mnt > mount: /dev/md2s1: Invalid argument > > root@host0:/vms/138# mount -t ext2fs /dev/md2s2 /mnt > mount: /dev/md2s2: Invalid argument > > root@host0:/vms/138# mount -t ext2fs /dev/md2s5 /mnt > mount: /dev/md2s5: Invalid argument > > As I understand it, this driver should also read ext3. Maybe bhyve does > something meaning the filesystem in the image isn't readable as the > installed filesystem of the image, to the host? > > Do you have any other suggestions? Try: file -s /dev/md2s1 file -s /dev/md2s2 file -s /dev/md2s5 If I understand correctly, the default Ubuntu partitioning is for partition 1 (s1) to be the boot/root partition, partition 2 to be an "extended" partition which contains partition 5, the swap partition. It's also possible you used LVM and that could hide the paritions inside other ones. FreeBSD can parse LVM if you load the geom_linux_lvm kernel module. Regards, Gary From owner-freebsd-fs@freebsd.org Fri Nov 11 16:14:05 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1734DC3AE0F for ; Fri, 11 Nov 2016 16:14:05 +0000 (UTC) (envelope-from julien@perdition.city) Received: from relay-b03.edpnet.be (relay-b03.edpnet.be [212.71.1.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "edpnet.email", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2783186C for ; Fri, 11 Nov 2016 16:14:04 +0000 (UTC) (envelope-from julien@perdition.city) X-ASG-Debug-ID: 1478879856-0a88184196d6300001-3nHGF7 Received: from mordor.lan (77.109.124.121.adsl.dyn.edpnet.net [77.109.124.121]) by relay-b03.edpnet.be with ESMTP id 5mm1o0JjAjm0Pkha (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Nov 2016 16:57:37 +0100 (CET) X-Barracuda-Envelope-From: julien@perdition.city X-Barracuda-Effective-Source-IP: 77.109.124.121.adsl.dyn.edpnet.net[77.109.124.121] X-Barracuda-Apparent-Source-IP: 77.109.124.121 Date: Fri, 11 Nov 2016 16:57:35 +0100 From: Julien Cigar To: Palle Girgensohn Cc: freebsd-fs@freebsd.org, Julian Akehurst Subject: Re: Best practice for high availability ZFS pool Message-ID: <20161111155735.GM81247@mordor.lan> X-ASG-Orig-Subj: Re: Best practice for high availability ZFS pool References: <5E69742D-D2E0-437F-B4A9-A71508C370F9@FreeBSD.org> <5DA13472-F575-4D3D-80B7-1BE371237CE5@getsomewhere.net> <8E674522-17F0-46AC-B494-F0053D87D2B0@pingpong.net> <5127A334-0805-46B8-9CD9-FD8585CB84F3@chittenden.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Z/kiM2A+9acXa48/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Barracuda-Connect: 77.109.124.121.adsl.dyn.edpnet.net[77.109.124.121] X-Barracuda-Start-Time: 1478879856 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://212.71.1.220:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 5586 X-Virus-Scanned: by bsmtpd at edpnet.be X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0100 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.34421 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 16:14:05 -0000 --Z/kiM2A+9acXa48/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 11, 2016 at 04:16:52PM +0100, Palle Girgensohn wrote: > Hi, >=20 > Pinging this old thread. >=20 > We have revisited this question: >=20 > A simple stable solution for a redundant storage with little or no down t= ime when a machine breaks. Storage is served using NFS only. >=20 >=20 > It seems true HA is always complicated. I'd rather go for a simple unders= tandable solution and accept sub minute downtime rather than a complicated = solution. For our needs, the pretty solution lined up in the FreeBSD Magazi= ne seems a bit overly complicated. >=20 > So here's what we are pondering: >=20 > - one SAS dual port disk box >=20 > - connect a master host machine to one port and a slave host machine to t= he the other port >=20 > - one host is MASTER, it serves all requests >=20 > - one host is SLAVE, doing nothing but waiting for the MASTER to fail >=20 > - fail over would be handled with zpool export / zpool import, or just zp= ool import -F if the master dies. >=20 > - MASTER/SLAVE election and avoiding split brain using for example CARP. >=20 > This is not a real HA solution since zpool import takes about a minute. I= s this true for a large array? >=20 > Would this suggestion work? I'm using someting like this here, a zpool over 2 local disks and 2 iscsi disks and the following failover script: https://gist.github.com/silenius/cb10171498071bdbf6040e30a0cab5c2 It works like a charm except that I'm having this issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211990=20 (apparently this problem does not appear on 11.0-RELEASE) >=20 > Are there better ideas out there? >=20 > Cheers, > Palle >=20 >=20 >=20 >=20 >=20 >=20 > > 18 maj 2016 kl. 09:58 skrev Sean Chittenden : > >=20 > > https://www.freebsdfoundation.org/wp-content/uploads/2015/12/vol2_no4_g= roupon.pdf > >=20 > > mps(4) was good to us. What=E2=80=99s your workload? -sc > >=20 > > -- > > Sean Chittenden > > sean@chittenden.org > >=20 > >=20 > >> On May 18, 2016, at 03:53 , Palle Girgensohn wro= te: > >>=20 > >>=20 > >>=20 > >>> 17 maj 2016 kl. 18:13 skrev Joe Love : > >>>=20 > >>>=20 > >>>> On May 16, 2016, at 5:08 AM, Palle Girgensohn w= rote: > >>>>=20 > >>>> Hi, > >>>>=20 > >>>> We need to set up a ZFS pool with redundance. The main goal is high = availability - uptime. > >>>>=20 > >>>> I can see a few of paths to follow. > >>>>=20 > >>>> 1. HAST + ZFS > >>>>=20 > >>>> 2. Some sort of shared storage, two machines sharing a JBOD box. > >>>>=20 > >>>> 3. ZFS replication (zfs snapshot + zfs send | ssh | zfs receive) > >>>>=20 > >>>> 4. using something else than ZFS, even a different OS if required. > >>>>=20 > >>>> My main concern with HAST+ZFS is performance. Google offer some insi= ghts here, I find mainly unsolved problems. Please share any success storie= s or other experiences. > >>>>=20 > >>>> Shared storage still has a single point of failure, the JBOD box. Ap= art from that, is there even any support for the kind of storage PCI cards = that support dual head for a storage box? I cannot find any. > >>>>=20 > >>>> We are running with ZFS replication today, but it is just too slow f= or the amount of data. > >>>>=20 > >>>> We prefer to keep ZFS as we already have a rather big (~30 TB) pool = and also tools, scripts, backup all is using ZFS, but if there is no soluti= on using ZFS, we're open to alternatives. Nexenta springs to mind, but I be= lieve it is using shared storage for redundance, so it does have single poi= nts of failure? > >>>>=20 > >>>> Any other suggestions? Please share your experience. :) > >>>>=20 > >>>> Palle > >>>=20 > >>> I don=E2=80=99t know if this falls into the realm of what you want, b= ut BSDMag just released an issue with an article entitled =E2=80=9CAdding Z= FS to the FreeBSD dual-controller storage concept.=E2=80=9D > >>> https://bsdmag.org/download/reusing_openbsd/ > >>>=20 > >>> My understanding in this setup is that the only single point of failu= re for this model is the backplanes that the drives would connect to. Depe= nding on your controller cards, this could be alleviated by simply using mu= ltiple drive shelves, and only using one drive/shelf as part of a vdev (the= n stripe or whatnot over your vdevs). > >>>=20 > >>> It might not be what you=E2=80=99re after, as it=E2=80=99s basically = two systems with their own controllers, with a shared set of drives. Some = expansion from the virtual world to real physical systems will probably nee= d additional variations. > >>> I think the TrueNAS system (with HA) is setup similar to this, only w= ithout the split between the drives being primarily handled by separate con= trollers, but someone with more in-depth knowledge would need to confirm/de= ny this. > >>>=20 > >>> -Jo > >>=20 > >> Hi, > >>=20 > >> Do you know any specific controllers that work with dual head? > >>=20 > >> Thanks., > >> Palle > >>=20 > >>=20 > >> _______________________________________________ > >> freebsd-fs@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs > >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > >=20 >=20 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" --=20 Julien Cigar Belgian Biodiversity Platform (http://www.biodiversity.be) PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. --Z/kiM2A+9acXa48/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJYJepsAAoJELK7NxCiBCPAIrEP/jHo0CcYTvOTQ25g7UgiVtJ+ S+L4WnlyW2NfXG5gAHMxouXertFemS7YgoO1+5zYeDd9V9I17mNF/R6K9nA96Bkv u3DrPCc5NkWUREBv1dskS5TQqkdyHSZ2wBrtKl2A+1S8bab8axOsGiqj3u+BL24E jRzOpu5osOv8HHN2tAsh9dNe9F+q4JZrvDTI1s9EiIwtqQdG3hhB+33dVBSBXEqc Wjll20O7y9UxTSexn+9/DNePKDrlcT+MHLS/nX+Wpo5fXKBU3Q3FoBkZTzxoqro6 Xx8/VDQQhqlYS+pqApEFZywP4on3zxdw69o4KcRH7oNISLI8kbipktFYQD1xXola Za72p/tS86Xt9xcge0F2mM/CBQkH7UfPNc6XYgYkRHHLadTsKoM1K4kmMrrSuxnD Vavd50AzhzMdyGAsAPbdg12+Vox+gzrYvFl/zWVJDQFl6sJj6U6jjr83e+G9amaf dyHNeFLcMEJvH2judrAPbBC/tQghjWllbzkVOSC3RhmXea77bxspWcGzxdD7Bjy6 1TMQ2DJGqY0eERDzqbx3LiPsXgnnqRK4Q/h380YXQkFkUpDk/a6jKAVWLCHnFT3p eTqr5KOQ49+qo1+Gux1bBO53YgC7qXLh+ocEQLO5smBjn+ik4jzB4V/nmMET7AAg JrG6as14ZC6j+WWeSJ/x =QYE3 -----END PGP SIGNATURE----- --Z/kiM2A+9acXa48/-- From owner-freebsd-fs@freebsd.org Fri Nov 11 22:25:44 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A8D2C3CAA7 for ; Fri, 11 Nov 2016 22:25:44 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0094.outbound.protection.outlook.com [157.56.110.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 213421870 for ; Fri, 11 Nov 2016 22:25:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0192.CANPRD01.PROD.OUTLOOK.COM (10.165.218.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Fri, 11 Nov 2016 22:25:35 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0707.013; Fri, 11 Nov 2016 22:25:35 +0000 From: Rick Macklem To: Jason Mader , "freebsd-fs@freebsd.org" Subject: Re: Mount protocol/showmount vs NFSv4 Thread-Topic: Mount protocol/showmount vs NFSv4 Thread-Index: AQHSOG1Vi/9I8/Ov0UO2Epz4od6j/qDQvUCAgAOmbMw= Date: Fri, 11 Nov 2016 22:25:35 +0000 Message-ID: References: , <46BE3C1E-BC1B-4D48-95D4-45F61F7AD238@gmu.edu> In-Reply-To: <46BE3C1E-BC1B-4D48-95D4-45F61F7AD238@gmu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0192; 7:ijb+jk1pT936XKxhuHzAy86YAszT4r5ehkynNMA7lrsUes2V7cVyhjbqtYSrhl+DE3C/T4qSo30e5AfoQI71lvpzqcZ7lHiZXuTMIxpccipyJ06axaqW6PNgPzBN41VocGb+1oXV5uz6sifC3ivHW1ILn17PMMOwDGtPH1hqVI+A95+UMaiMgvS0pEmkOyB6PVsFdmFAe3zFAvHNaJLQwXRPhrulb+JJ1yCcpqYwyTo/emlogH+4HZ4vxi6uqqCZBYeqs09uT8K2Ee80EHPG8EomDPRP151QbMd8/hItLp8lttLGJuh0AomlUpE0Duw8SAwDJYSAzHM+baEU4XdqwoDW1zHCw4E+hqavxb9BByk= x-ms-office365-filtering-correlation-id: f9e751f8-467f-4eac-258e-08d40a81a817 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0192; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(75325880899374)(13783010486086); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6042046)(6043046); SRVR:YTXPR01MB0192; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0192; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(377454003)(24454002)(199003)(81166006)(8676002)(81156014)(74482002)(8936002)(2171001)(7696004)(74316002)(5660300001)(3280700002)(77096005)(101416001)(87936001)(229853002)(7846002)(8666005)(3660700001)(122556002)(2501003)(2950100002)(305945005)(9686002)(586003)(105586002)(106356001)(106116001)(86362001)(102836003)(2906002)(107886002)(97736004)(5001770100001)(68736007)(76176999)(50986999)(54356999)(92566002)(2900100001)(33656002)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0192; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2016 22:25:35.0998 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0192 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 22:25:44 -0000 I have just put a patch for umount(8) here that makes it do the Unmount RPC= over TCP for NFSv3/TCP mounts and not do the Unmount RPC for NFSv4 mounts. reviews.freebsd.org/D8503 Colin, maybe you could review this? Thanks, rick ________________________________________ From: owner-freebsd-fs@freebsd.org on behalf= of Jason Mader Sent: Wednesday, November 9, 2016 9:39:19 AM To: freebsd-fs@freebsd.org Subject: Re: Mount protocol/showmount vs NFSv4 On 6 Nov 2016, at 15:51, Rick Macklem wrote: > NFSv2 and NFSv3 use a protocol called Mount (implemented by mountd) to > try and > track mounts/unmounts and report exports to clients. Except for the > one RPC that > maps a directory path to a File Handle, none of this is needed by NFS. > The rest is > reported (and never guaranteed to be correct) by showmount(8). > > There are a couple of issues related to the Mount protocol. > 1 - It uses a dynamically assigned port# via rpcbind (which means > hassles for firewalls, etc). > 2 - umount(8) currently assumes that it is supported over UDP and > fails if it is > configured to work over TCP only. > 3 - A recent issue was reported where there is a delay for systems > configured for IP6 > only related to the handling of localhost. (I'll admit I didn't > understand quite why > there was this 2sec delay, but others familiar with networking > confirmed it was > correct behaviour.) > > NFSv4 doesn't use the Mount protocol at all and does everything via > the NFSv4 protocol > serviced at port #2049. > I have never done anything about this, since most were still using > NFSv3, but it seems > that maybe something should be done now? > - What do people think of having a new option on mountd(8) that would > be used for > NFSv4 only servers that disables servicing of Mount RPCs. > --> This would imply that "showmount" would no longer work for it. > --> Note that "showmount" returns nothing useful for NFSv4 > mounts, since mountd > doesn't know about NFSv4 mounts (and the NFSv4 server > doesn't know either, > because there is no concept of a "mount" in the NFSv4 > protocol). > --> It does imply that "showmount -e" will stop working and > that info might be > useful w.r.t. NFSv4 servers. > > Umount(8) for NFSv3 is a slightly different problem. It has (for > 30years) just talked to > UDP. If that doesn't work, there is a delay, but the umount still > works (and the info > from "showmount" is no longer correct, but it is never guaranteed to > be correct anyhow). > - Should umount(8) use TCP if the NFSv3 mount is using TCP? > --> This could cause it to break for a case where only UDP is > supported for the Mount > protocol on the server, but that would be a rare/broken case, > I'd guess. > > Anyhow, any/all comments on this would be appreciated, rick I agree that the NFS client can be improved to not try to contact the RPC server for an NFSv4 mount. The Linux NFS client already doesn=92t. A possible bug: the NFS server picks up it=92s NFSv4-only behavior from vfs.nfsd.server_min_nfsvers, but nfsd still registers 2 & 3 with rpcbind, 100003 2 tcp 0.0.0.0.8.1 nfs superuser 100003 3 tcp 0.0.0.0.8.1 nfs superuser 100003 2 tcp6 ::.8.1 nfs superuser 100003 3 tcp6 ::.8.1 nfs superuser In nfsd.c the value of vfs.nfsd.server_min_nfsvers is not checked before registering sockets with rpcbind. In my use, I would like mountd to adjust it=92s behavior when vfs.nfsd.server_min_nfsvers > 3 and, by default, only listen on 127.0.0.1 and ::1. When additional addresses are needed they could then be added by the existing -h flag. Then mountd may not need to register the sockets with rpcbind at all. Then starting rpcbind could be eliminated to run an NFSv4-only server. (Guard the force_depend rpcbind in mountd and nfsd command scripts) `showmount -e` will still want to contact an RPC server though. Even when NFSv4-only, I=92m currently using the output of `showmount -E` to obtain the list of filesystems that already are automatically exported with the ZFS property sharenfs. This is because I need an additional -network flag on each filesystem, scripted when /etc/zfs/exports changes, and haven=92t found a better way to get two -network flags per filesystem. There is a possible improvement to ZFS when sharenfs has multiple -network flags, to write them as additional lines in /etc/zfs/exports. Then I would have no need for showmount at all, or for it=92s behavior to be changed. But the two minute delay on `showmount -e` happens when rpcbind is started with the -6 flag. This is being called correct behavior, but it is rather odd behavior on the transition to IPv6-only. -- Jason Mader _______________________________________________ freebsd-fs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Sat Nov 12 09:41:12 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 196C0C3B004 for ; Sat, 12 Nov 2016 09:41:12 +0000 (UTC) (envelope-from 0100015857e97ed8-b45e0929-6c68-4e67-9bc5-31b5a95dd9b7-000000@amazonses.com) Received: from a8-52.smtp-out.amazonses.com (a8-52.smtp-out.amazonses.com [54.240.8.52]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CEE48197A for ; Sat, 12 Nov 2016 09:41:11 +0000 (UTC) (envelope-from 0100015857e97ed8-b45e0929-6c68-4e67-9bc5-31b5a95dd9b7-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=vnqrkfnvu6csdl6mwgk5t6ix3nnepx57; d=tarsnap.com; t=1478943670; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=BTKx/HFmGiQK83oYAg8Z6hrfR+2x5z9echX/ax1Jkbg=; b=VHhBRYAz/vvwXaME4s47H6Y44tXvX0f/5dhIm2pTeAqZ1k8AC0JbgHJHJguylmx1 5+HOsVi/GBI7aCCU4628XcX70KhAuigSmBtYSD5+8lDQcPsQH+wsCyVmv/mylAZ4k8h O1VqOUgeYnCXvOwNf3N9e75HNqYU1Pympy4N8OHM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1478943670; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=BTKx/HFmGiQK83oYAg8Z6hrfR+2x5z9echX/ax1Jkbg=; b=ZupVSZ+IkDKkBqsEXRZCnA8IxHTa8OWt/kE1MpGgimtiZ5gD9Gk9l2JByn7zH6/I nsFCNSWiOijvVuP4625PQhkTdOE4Zm7zbYEORVwe5bZ6kDdRFu/wisjEShWbIzkNg1y 0mMckb/nCkrq6N0cxlACOZXGXiCPHA7l8TvK63L4= Subject: Re: Mount protocol/showmount vs NFSv4 To: Rick Macklem , Jason Mader , "freebsd-fs@freebsd.org" References: <46BE3C1E-BC1B-4D48-95D4-45F61F7AD238@gmu.edu> From: Colin Percival Message-ID: <0100015857e97ed8-b45e0929-6c68-4e67-9bc5-31b5a95dd9b7-000000@email.amazonses.com> Date: Sat, 12 Nov 2016 09:41:10 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SES-Outgoing: 2016.11.12-54.240.8.52 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 09:41:12 -0000 On 11/11/16 14:25, Rick Macklem wrote: > I have just put a patch for umount(8) here that makes it do the Unmount RPC over TCP > for NFSv3/TCP mounts and not do the Unmount RPC for NFSv4 mounts. > reviews.freebsd.org/D8503 > > Colin, maybe you could review this? Aside from one very minor bug, it works fine for NFSv4. But I can't confirm about other NFS versions. Colin Percival > ________________________________________ > From: owner-freebsd-fs@freebsd.org on behalf of Jason Mader > Sent: Wednesday, November 9, 2016 9:39:19 AM > To: freebsd-fs@freebsd.org > Subject: Re: Mount protocol/showmount vs NFSv4 > > On 6 Nov 2016, at 15:51, Rick Macklem wrote: > >> NFSv2 and NFSv3 use a protocol called Mount (implemented by mountd) to >> try and >> track mounts/unmounts and report exports to clients. Except for the >> one RPC that >> maps a directory path to a File Handle, none of this is needed by NFS. >> The rest is >> reported (and never guaranteed to be correct) by showmount(8). >> >> There are a couple of issues related to the Mount protocol. >> 1 - It uses a dynamically assigned port# via rpcbind (which means >> hassles for firewalls, etc). >> 2 - umount(8) currently assumes that it is supported over UDP and >> fails if it is >> configured to work over TCP only. >> 3 - A recent issue was reported where there is a delay for systems >> configured for IP6 >> only related to the handling of localhost. (I'll admit I didn't >> understand quite why >> there was this 2sec delay, but others familiar with networking >> confirmed it was >> correct behaviour.) >> >> NFSv4 doesn't use the Mount protocol at all and does everything via >> the NFSv4 protocol >> serviced at port #2049. >> I have never done anything about this, since most were still using >> NFSv3, but it seems >> that maybe something should be done now? >> - What do people think of having a new option on mountd(8) that would >> be used for >> NFSv4 only servers that disables servicing of Mount RPCs. >> --> This would imply that "showmount" would no longer work for it. >> --> Note that "showmount" returns nothing useful for NFSv4 >> mounts, since mountd >> doesn't know about NFSv4 mounts (and the NFSv4 server >> doesn't know either, >> because there is no concept of a "mount" in the NFSv4 >> protocol). >> --> It does imply that "showmount -e" will stop working and >> that info might be >> useful w.r.t. NFSv4 servers. >> >> Umount(8) for NFSv3 is a slightly different problem. It has (for >> 30years) just talked to >> UDP. If that doesn't work, there is a delay, but the umount still >> works (and the info >> from "showmount" is no longer correct, but it is never guaranteed to >> be correct anyhow). >> - Should umount(8) use TCP if the NFSv3 mount is using TCP? >> --> This could cause it to break for a case where only UDP is >> supported for the Mount >> protocol on the server, but that would be a rare/broken case, >> I'd guess. >> >> Anyhow, any/all comments on this would be appreciated, rick > > I agree that the NFS client can be improved to not try to contact the > RPC server for an NFSv4 mount. The Linux NFS client already doesn�t. > > A possible bug: the NFS server picks up it�s NFSv4-only behavior from > vfs.nfsd.server_min_nfsvers, but nfsd still registers 2 & 3 with > rpcbind, > > 100003 2 tcp 0.0.0.0.8.1 nfs > superuser > 100003 3 tcp 0.0.0.0.8.1 nfs > superuser > 100003 2 tcp6 ::.8.1 nfs > superuser > 100003 3 tcp6 ::.8.1 nfs > superuser > > In nfsd.c the value of vfs.nfsd.server_min_nfsvers is not checked before > registering sockets with rpcbind. > > In my use, I would like mountd to adjust it�s behavior when > vfs.nfsd.server_min_nfsvers > 3 and, by default, only listen on > 127.0.0.1 and ::1. When additional addresses are needed they could then > be added by the existing -h flag. Then mountd may not need to register > the sockets with rpcbind at all. Then starting rpcbind could be > eliminated to run an NFSv4-only server. (Guard the force_depend rpcbind > in mountd and nfsd command scripts) > > `showmount -e` will still want to contact an RPC server though. > > Even when NFSv4-only, I�m currently using the output of `showmount -E` > to obtain the list of filesystems that already are automatically > exported with the ZFS property sharenfs. This is because I need an > additional -network flag on each filesystem, scripted when > /etc/zfs/exports changes, and haven�t found a better way to get two > -network flags per filesystem. There is a possible improvement to ZFS > when sharenfs has multiple -network flags, to write them as additional > lines in /etc/zfs/exports. Then I would have no need for showmount at > all, or for it�s behavior to be changed. > > But the two minute delay on `showmount -e` happens when rpcbind is > started with the -6 flag. This is being called correct behavior, but it > is rather odd behavior on the transition to IPv6-only. > > -- > Jason Mader > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-fs@freebsd.org Sat Nov 12 10:44:37 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BCBFC3C540 for ; Sat, 12 Nov 2016 10:44:37 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 17C681D1E; Sat, 12 Nov 2016 10:44:37 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [IPv6:2001:470:923f:2:5c87:58af:6791:eb29] (unknown [IPv6:2001:470:923f:2:5c87:58af:6791:eb29]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id EA63E235; Sat, 12 Nov 2016 13:44:34 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: ZFS L2ARC checksum errors after compression References: <921575537.20161029143626@serebryakov.spb.ru> <3dae7691-fcd1-b3b9-445c-b81d6f0cdc52@FreeBSD.org> <3bd7cb79-ec5a-3b7c-0642-24a7b1f001e6@FreeBSD.org> To: Andriy Gapon , freebsd-fs From: Lev Serebryakov Organization: FreeBSD Message-ID: <5826F293.7020408@FreeBSD.org> Date: Sat, 12 Nov 2016 13:44:35 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <3bd7cb79-ec5a-3b7c-0642-24a7b1f001e6@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 10:44:37 -0000 > because of the confusing variable names I made a mistake in the patch that I > offered you. Could you please try a new slight different patch? > Also, I think that there could be another problem in addition to the one that I > see. But I am quite busy at the moment, no time to investigate. Maybe on the > weekend or some time next week. Nope. Second version of patch doesn't help either. Still unrealistic high compression ratio (ALLOC/SIZE, slightly less than 2 on mostly uncompresseable data), 16.0E of FREE since ALLOC becomes greater than SIZE and lot of checksum errors since the same moment. -- // Lev Serebryakov AKA Black Lion From owner-freebsd-fs@freebsd.org Sat Nov 12 11:57:10 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9BF39C3D761 for ; Sat, 12 Nov 2016 11:57:10 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BBC0C17AE; Sat, 12 Nov 2016 11:57:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA27902; Sat, 12 Nov 2016 13:57:02 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1c5Wvd-000A2R-Pw; Sat, 12 Nov 2016 13:57:01 +0200 Subject: Re: ZFS L2ARC checksum errors after compression To: lev@FreeBSD.org, freebsd-fs References: <921575537.20161029143626@serebryakov.spb.ru> <3dae7691-fcd1-b3b9-445c-b81d6f0cdc52@FreeBSD.org> <3bd7cb79-ec5a-3b7c-0642-24a7b1f001e6@FreeBSD.org> <5826F293.7020408@FreeBSD.org> From: Andriy Gapon Message-ID: <5695c647-9250-703d-35d8-8b125dbcd61b@FreeBSD.org> Date: Sat, 12 Nov 2016 13:56:05 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5826F293.7020408@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 11:57:10 -0000 On 12/11/2016 12:44, Lev Serebryakov wrote: > >> because of the confusing variable names I made a mistake in the patch that I >> offered you. Could you please try a new slight different patch? >> Also, I think that there could be another problem in addition to the one that I >> see. But I am quite busy at the moment, no time to investigate. Maybe on the >> weekend or some time next week. > > Nope. Second version of patch doesn't help either. Still unrealistic > high compression ratio (ALLOC/SIZE, slightly less than 2 on mostly > uncompresseable data), 16.0E of FREE since ALLOC becomes greater than > SIZE and lot of checksum errors since the same moment. > I see. Could you please send me full output of the following commands? zpool status -v zpool list -v zdb -CC $pool -- Andriy Gapon