From owner-freebsd-bugs@freebsd.org Fri Apr 19 22:54:48 2019 Return-Path: Delivered-To: freebsd-bugs@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 D593C157B364 for ; Fri, 19 Apr 2019 22:54:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 697786F378 for ; Fri, 19 Apr 2019 22:54:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2CE3D157B362; Fri, 19 Apr 2019 22:54:47 +0000 (UTC) Delivered-To: bugs@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 08F22157B361 for ; Fri, 19 Apr 2019 22:54:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99D676F376 for ; Fri, 19 Apr 2019 22:54:46 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id B858A1DBAF for ; Fri, 19 Apr 2019 22:54:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3JMsjcW028164 for ; Fri, 19 Apr 2019 22:54:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3JMsjGZ028163 for bugs@FreeBSD.org; Fri, 19 Apr 2019 22:54:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 237397] 'zfs mount -a' mounts filesystems in incorrect order Date: Fri, 19 Apr 2019 22:54:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: freebsd-bugzilla@umpquanet.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: 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-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 22:54:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237397 Bug ID: 237397 Summary: 'zfs mount -a' mounts filesystems in incorrect order Product: Base System Version: 12.0-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: freebsd-bugzilla@umpquanet.com I have a system that boots from ZFS. I recently upgraded it from FreeBSD 11.2-STABLE to 12.0-STABLE. FreeBSD electron 12.0-STABLE FreeBSD 12.0-STABLE r346293 GENERIC amd64 I upgraded source, and rebooted into the new 12-STABLE kernel with no problems. After installworld and mergemaster, I discovered that certain ZFS filesystems were not auto-mounting in the correct sequence, "correct" meaning that /a mounts before /a/b mounts before /a/b/c. Here are the mountable filesystems on that machine (canmount !=3D off): electron : 15:36:37 /root# zfs get -Hrt filesystem canmount | grep -vw off | while read FS b; do echo $FS; done | xargs zfs list -o name,canmount,mounted,mountpoint NAME CANMOUNT MOUNTED MOUNTPOINT electron on no none electron/data on no /data electron/data/backup on no /data/backup electron/data/backup/jimsdesk on no /data/backup/jimsdesk electron/system on no none electron/system/ROOT on no none electron/system/ROOT/default on yes / electron/system/home on yes /home electron/system/tmp on yes /tmp electron/system/usr on yes /usr electron/system/usr/local on yes /usr/local electron/system/var on yes /var The easiest tree to demonstrate with is electron/data and children, although this problem is also happening with electron/system/usr and children. I have not found any way to query the ZFS stack as to what it thinks the correct mount order should be, and thus demonstrate whether the automatic mounting order is correct. However, I have fashioned this test script to highlight the observable differences between a correct, manual mounting, and the incorrect mount order used by zfs mount -a: --snip-- #!/usr/bin/env bash # correct mount ordering: MANUAL=3D" zfs mount electron/data zfs mount electron/data/backup zfs mount electron/data/backup/jimsdesk " # automatic mount ordering: AUTO=3D" zfs mount -va " case $1 in manual) MOUNT=3D"$MANUAL" ;; auto) MOUNT=3D"$AUTO" ;; *) exit esac cat << EOF | sh -v zfs mount | grep '/data' mkdir /data find /data $MOUNT zfs mount | grep '/data' find /data | head -3000000 | wc -l zfs umount /data/backup/jimsdesk zfs umount /data/backup zfs umount /data rmdir /data find /data EOF --snip-- Here's a run of that script using the manual mounting order. The mountpoint /data is created fresh at the start. When the filesystems are correctly mounted, there are over 3 million files under /data. After unmounting, /data is empty, and can be rmdir'ed. --snip-- electron : 12:26:00 /root# ./zfs-mount-test.sh manual zfs mount | grep '/data' mkdir /data find /data /data zfs mount electron/data zfs mount electron/data/backup zfs mount electron/data/backup/jimsdesk zfs mount | grep '/data' electron/data /data electron/data/backup /data/backup electron/data/backup/jimsdesk /data/backup/jimsdesk find /data | head -3000000 | wc -l 3000000 zfs umount /data/backup/jimsdesk zfs umount /data/backup zfs umount /data rmdir /data find /data find: /data: No such file or directory --snip-- Here's a run of that script using the automatic mounting order. When the filesystems are automatically mounted, fewer than 1.5 million files are present under /data. Unmounting everything generates an error message, /data is not clean, and rmdir returns an error. --snip-- electron : 12:26:17 /root# ./zfs-mount-test.sh auto zfs mount | grep '/data' mkdir /data find /data /data zfs mount -va zfs mount | grep '/data' electron/data /data electron/data/backup /data/backup electron/data/backup/jimsdesk /data/backup/jimsdesk find /data | head -3000000 | wc -l 1481445 zfs umount /data/backup/jimsdesk zfs umount /data/backup cannot unmount '/data/backup': not a mountpoint zfs umount /data rmdir /data rmdir: /data: Directory not empty find /data /data /data/backup --snip-- Please let me know how I can provide additional information or testing. Thank you! Jim --=20 You are receiving this mail because: You are the assignee for the bug.=