From owner-svn-src-head@freebsd.org Wed Feb 27 13:24:48 2019 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B460E151D3C6 for ; Wed, 27 Feb 2019 13:24:48 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F36A76946; Wed, 27 Feb 2019 13:24:47 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id yzCPg88pVzrlPyzCQgvxMw; Wed, 27 Feb 2019 06:24:39 -0700 X-Authority-Analysis: v=2.3 cv=HIC96blv c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=CFTnQlWoA9kA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=J4m5mNcAyt45NkiF-P8A:9 a=g6jMdkWcIO0SC0-6:21 a=HjBQ2OW3PPJyF8c-:21 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id DB71FB94; Wed, 27 Feb 2019 05:24:36 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x1RDOa0h016851; Wed, 27 Feb 2019 05:24:36 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x1RDOaVf016848; Wed, 27 Feb 2019 05:24:36 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201902271324.x1RDOaVf016848@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Andriy Gapon cc: Cy Schubert , Baptiste Daroussin , src-committers , svn-src-head@FreeBSD.org, Jack Halford Subject: Re: svn commit: r344569 - in head/cddl/contrib/opensolaris: cmd/zfs lib/libzfs/common In-Reply-To: Message from Andriy Gapon of "Wed, 27 Feb 2019 15:10:00 +0200." <19c0f590-4327-d2c8-4660-bd9f5df12b50@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Feb 2019 05:24:36 -0800 X-CMAE-Envelope: MS4wfLu4uCz0Kl1Zozn21yHW8Wr65qJM14KGbwfPNAU+HE/1UOdz2GlqhLdTpzp6luOGin6nfCEoEfArTQNXlqDGSCZaNrg928afkPS3Thh/F39UFuj+urC+ 15l+lyyPbMEqaTBuwg1F5D4YiP6Gx6yqgOE0FmzncXdAoURMX+ah+I9VtGA4sMSDShIix5KRUHINGpFA32EpqbpNjM8CjF5zU5G81mb6J3SPZvE0+wAIp8pk 55F0xeD6nie+Jr8NBqN5CWHtjLKkKs+3Bl9R/9MPNJ5yBdgCuWg7CtjOGB+EBNsYEnSrv8sxyLXH6ThxWky+8Q== X-Rspamd-Queue-Id: 5F36A76946 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-4.67 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCPT_COUNT_FIVE(0.00)[6]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.96)[-0.957,0]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.01)[ip: (-5.22), ipnet: 64.59.128.0/20(-2.65), asn: 6327(-2.08), country: CA(-0.09)]; RCVD_IN_DNSWL_LOW(-0.10)[9.134.59.64.list.dnswl.org : 127.0.5.1] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 13:24:48 -0000 In message <19c0f590-4327-d2c8-4660-bd9f5df12b50@FreeBSD.org>, Andriy Gapon wri tes: > On 27/02/2019 15:04, Cy Schubert wrote: > > In message <0563e72c-c9e3-a476-ce43-d4a67c454508@FreeBSD.org>, Andriy > > Gapon wri > > tes: > >> On 26/02/2019 22:58, Cy Schubert wrote: > >>> I was talking about nested datasets, i.e. tank/freebsd/git/current and > >>> tank/freebsd/git/ports are four levels deep. > >> > >> We usually don't call them "nested". In fact, I don't think that we call > the > >> m > >> anything special because having N levels deep datasets (N > 1) is just a c > omm > >> on > >> thing. We may call them subordinate or child datasets when mentioning a > >> relation to a parent dataset. > >> > >>> In my case the ports > >>> dataset was mounted while the current dataset was not, though zfs > >>> believed it was. unmounting the current dataset and remounting it, zfs > >>> umount .../current; zfs mount .../current worked around the issue. > >> > >> Are you sure that it was not mounted? > > > > Yes. > > > >> Have you checked that by looking at mount output? > > > > Yes > > > >> I suspect that it was mounted, just not where you expected and its mount p > ath > >> was covered by another filesystem. > > > > If you read my original email > > Apologies, I failed to read your original email when I first saw it. > I pressed Page Down a few times but was still seeing only a quoted text, so I > gave up. That was my fault but given I was using an email client on my phone, removing the quoted text would have taken forever. Usually in that circumstance I wait until I get to a real keyboard before firing off an email. > > > a zfs umount followed by a zfs mount for > > each affected filesystem worked around the problem. zfs properties > > showed that each and every filesystem was mounted. mount(1) and df(1) > > confirmed they were not. Furthermore nullfs mounts with the late > > attribute failed to mount because their underlying zfs datasets were > > not mounted -- this is what clued me into the problem in the first > > place, a FreeBSD system dropping into single user at boot. And, no, > > fstab on that machine had not been changed for months, them machine > > failed to boot. So, no, I was not mistaken. I was rather displeased > > because I had to try to fix the problem using ssh on a phone to a > > machine connected to a console server. > > > >> > >> E.g., lets consider this hypothetical case. > >> I have two same level datasets tank/freebsd/src and tank/freebsd/sys where > >> tank/freebsd/src is mounted at /usr/src and tank/freebsd/sys is mounted at > >> /usr/src/sys (a child directory of /usr/src). > >> If tank/freebsd/src is mounted first, then everything is okay, tank/freebs > d/s > >> ys > >> would be mounted on top of sys directory in tank/freebsd/src. > >> If, however, tank/freebsd/sys is mounted first (assuming that path /usr/sr > c/s > >> ys > >> exists in a root filesystem), then mounting tank/freebsd/src would simply > hid > >> e > >> tank/freebsd/sys "below" it as /usr/src/sys would be sys directory in > >> tank/freebsd/src. > >> > >> I guess that this is a kind of problem that could be introduced with paral > lel > >> mounting. And I guess that this is a kind of problem that you might actua > lly > >> have. But it's just a guess. > > > > No. I had not mistakenly mounted the datasets elsewhere, mistakenly > > deleted them or mistakenly changed their mount attributes. It was a > > real, not imagined, regression fixed by the patch posted near the end > > of the email thread. > > Okay. Great that it is fixed and sorry for my noise. NP. I'm glad it's fixed too. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.