From owner-freebsd-fs@freebsd.org Sun Apr 9 10:30:33 2017 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 C3504D34D17 for ; Sun, 9 Apr 2017 10:30:33 +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 B352ECB2 for ; Sun, 9 Apr 2017 10:30:33 +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 v39AUXmK004446 for ; Sun, 9 Apr 2017 10:30:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 218501] ZFS inherited filesystem ACLs don't update Date: Sun, 09 Apr 2017 10:30:33 +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-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some 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 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, 09 Apr 2017 10:30:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218501 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun Apr 9 21:00:56 2017 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 8F57CD361BC for ; Sun, 9 Apr 2017 21:00:56 +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 812971FA1 for ; Sun, 9 Apr 2017 21:00:56 +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 v39L010e010629 for ; Sun, 9 Apr 2017 21:00:56 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201704092100.v39L010e010629@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, 09 Apr 2017 21:00:56 +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, 09 Apr 2017 21:00:56 -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 New | 217062 | for file systems mounted with -o noexec, exec=off 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 | 211491 | System hangs after "Uptime" on reboot with ZFS 7 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Tue Apr 11 17:41:00 2017 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 2EDB5D39C97 for ; Tue, 11 Apr 2017 17:41:00 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F4170979 for ; Tue, 11 Apr 2017 17:40:59 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-io0-x233.google.com with SMTP id a103so11712468ioj.1 for ; Tue, 11 Apr 2017 10:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=1TcX0ojHUB+F4/k7U6APIdIrg29Of2ZXmIZIqcy0cFQ=; b=GnZMXrF9yQOKpMSFJzR21Zj32L5mJ6XfdPubPHL1HInmBGQkv5hVKZFrNPQ/w1k99y cHKuQwJV/leoeIJi/MpzWemMbhoV9g8gGU5YEB9BQ0/IFSCNFACeN4U+IFYQM6LeJ6jY ZqjKopGmwSmqtJl+jToSwzWz8BfCkYct6lPycp0c1+6F2/6n6ojc541yhsAg16/k6ybM w28x0CszHBUZXLNo3pCn7VmqRYC9L3X1Li5KzzW2aeFpds7Z/wEqGk1T9zSzDBSj20Op MZ7WPwGQMo6uiYzt4YViO9xcuNsa/OL2HhtqMXMg13j6QFs+yhxgie31O8E0YDt2KylA e5YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=1TcX0ojHUB+F4/k7U6APIdIrg29Of2ZXmIZIqcy0cFQ=; b=MDhwZVF32DBRSeIYDm/jZNoLomqZtLLwqjtcU0DHePDoyY+QlAtA906A80BdRlwhwT NQfgFTpiLlVec0T3gFgPCSkwu/4T/4oN/Vl4UoOcKv0dZJEp44h3+n25alACflo8Oha7 KC4vfCuBHk2SeANl+cWwm73LlNE57E0CvxeM9cwE+tGwUyNvMDeBBkDdEOGw/alaD6LA 7wtElzX30H1ONqvUWuyqIm5fdQRKo2StfnYZf3pblE+ES+Ee2/tYvH4HNFlEEf66wGfw BomvhtQtNvXCaNFmfKCxOSEQ9yK8N8VUhnb+w299FHCkkCPNbd6uxIWWkM7MOGCtbM45 ZD3w== X-Gm-Message-State: AFeK/H0x5ODEuJW1ZZQWLyfKVObyGgguwQ/6NpLXexFx2FwBZSTczqIQExISJL3LGy1HZglpGg5gHq9mH3DwKO+A X-Received: by 10.107.171.67 with SMTP id u64mr56783925ioe.102.1491932459146; Tue, 11 Apr 2017 10:40:59 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.112.210 with HTTP; Tue, 11 Apr 2017 10:40:58 -0700 (PDT) From: Maxim Sobolev Date: Tue, 11 Apr 2017 10:40:58 -0700 X-Google-Sender-Auth: G_LBqOcCCtxZZElf9Cpp0OWpnpc Message-ID: Subject: mksnap_ffs(8) is not working while chrooted To: Kirk McKusick , FreeBSD Filesystems 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: Tue, 11 Apr 2017 17:41:00 -0000 Hi Kirk et al, I've stumbled upon problem that it is impossible to use mksnap_ffs(8) while in the chrooted environment. Other utilities that manipulate fs'es (i.e. mount(8) / umount(8)) work just fine. Quick glance through the code shows that the problem stems from the fact that mksnap_ffs uses f_mntonname returned by the statfs(2) system call to fill fspath parameter for the nmount call. And the statfs() returns f_mntonname path outside chroot. As far as I can see, there are two options to address this issue. 1. Adjust statfs(2) system call to substract chroot prefix while returning f_mntonname. Similar to what prison_enforce_statfs() function does for jails. 2. Enhance nmount(2) to allow taking FSID in place of mount path to do resolution using existing flag MNT_BYFSID and adjust mksnap_ffs to use that instead. This is what umount(8) does to work around the problem. Which of two approaches would be preferred solution if any? The second one seems a bit simpler to me. Please advise. Thanks! -Max From owner-freebsd-fs@freebsd.org Tue Apr 11 18:06:42 2017 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 A7DE3D3A71C for ; Tue, 11 Apr 2017 18:06:42 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) (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 9055AC8E; Tue, 11 Apr 2017 18:06:41 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id v3BI7PGM001952; Tue, 11 Apr 2017 11:07:25 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201704111807.v3BI7PGM001952@chez.mckusick.com> From: Kirk McKusick To: Maxim Sobolev Subject: Re: mksnap_ffs(8) is not working while chrooted cc: FreeBSD Filesystems In-reply-to: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1950.1491934045.1@chez.mckusick.com> Date: Tue, 11 Apr 2017 11:07:25 -0700 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, 11 Apr 2017 18:06:42 -0000 > From: Maxim Sobolev > Date: Tue, 11 Apr 2017 10:40:58 -0700 > Subject: mksnap_ffs(8) is not working while chrooted > To: Kirk McKusick , > FreeBSD Filesystems > > Hi Kirk et al, > > I've stumbled upon problem that it is impossible to use mksnap_ffs(8) while > in the chrooted environment. Other utilities that manipulate fs'es (i.e. > mount(8) / umount(8)) work just fine. Quick glance through the code shows > that the problem stems from the fact that mksnap_ffs uses f_mntonname > returned by the statfs(2) system call to fill fspath parameter for the > nmount call. And the statfs() returns f_mntonname path outside chroot. As > far as I can see, there are two options to address this issue. > > 1. Adjust statfs(2) system call to substract chroot prefix while > returning f_mntonname. Similar to what prison_enforce_statfs() function > does for jails. > > 2. Enhance nmount(2) to allow taking FSID in place of mount path to do > resolution using existing flag MNT_BYFSID and adjust mksnap_ffs to use that > instead. This is what umount(8) does to work around the problem. > > Which of two approaches would be preferred solution if any? The second one > seems a bit simpler to me. Please advise. Thanks! > > -Max It is not secure to allow mksnap_ffs(8) to work inside a jail. The issue is that mksnap_ffs takes a snapshot of the entire filesystem. Based on the way that snapshots work in FFS, it is not possible to snapshot only the part of the filesystem that is in the jail. Thus, if you take a snapshot of the entire filesystem and then mount it inside the jail, you will expose parts of the filesystem from outside of the jail to the jail. As such, you should only be able to snapshot a filesystem if it is entirely contained within the jail. If snapshots within jails are important to you, I recommend that you use ZFS which allows you to create per-jail filesystems which you can then snapshot. Kirk McKusick From owner-freebsd-fs@freebsd.org Tue Apr 11 18:23:58 2017 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 93B3FD3A23F for ; Tue, 11 Apr 2017 18:23:58 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 6D960D71 for ; Tue, 11 Apr 2017 18:23:58 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-io0-x22f.google.com with SMTP id a103so13301849ioj.1 for ; Tue, 11 Apr 2017 11:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IrlRc7HMHS7hl1nOl0BAkxMJMToI9TH1rHrTn33fJiY=; b=gtdGVekgdlY1S4zsy9toGQeqag2oYTpGatsvJq/vkD9m/5U3OMoI+4ZqIBtrRkgfIy 5SoiipVfkBjrAajfczsjYQtKkEWjVJgFkd9q9koCrA8tdKHuATkoZNqsHU9Hh4MfELGp 2uN9J9x+DhQDw8ft520htk728W9uc1EkQx9Tfl2K2NvofRQ4deNl6JSiYDDyydRCywDI bQJInam+szENa52hcf1PVqVO2bRLQxS0W3G6Tom2506+mSbDYdvuF9cd0kH3tqoDpnzm +5it1en0oR4waCznHi/vG5U4Sa+PUs8q78m8IO2lGU390xWZYjNRYZE9hwi2NranVK3f JTxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=IrlRc7HMHS7hl1nOl0BAkxMJMToI9TH1rHrTn33fJiY=; b=pSFQpH8yhsBEILd6FfSAO0TcNtHdx9EQu1OehZD1z4RYR4rZ1drFfKkwIGArr8XLFj D3L462hxn4BsIehO3h5k73AXGoNHe5FvrYHnVAderiCiNdVqG/nYvR+2EPKD5miLkK9W tUKGm6dYWPlcAtfrTYm34B6i8zLhVYn8jkobHPRnseVYUlEBsE4o5mY1R/BaYQ26BNpz WplweQ1inEHzoeCLuQeF5a72r1UFyc7Q8hNUkPFXHXOk4ML9C3ZntMnYqxWoT542vssk QJvJpNRgASGdPF1RrHrEwo1uFBhLo2pzY8Em382ujKylVZuynEFKZ5QVPF1z5USRDEEo Rwkg== X-Gm-Message-State: AFeK/H03WVqNvfrcd/9nMTImnmeEp8dUOffvKqe4CRmOpk+le5+W/K5DaBQAh4UJ5Zb91PVXRarqdmlb4eXSgi+Z X-Received: by 10.107.203.7 with SMTP id b7mr59708840iog.115.1491935037535; Tue, 11 Apr 2017 11:23:57 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.112.210 with HTTP; Tue, 11 Apr 2017 11:23:57 -0700 (PDT) In-Reply-To: <201704111807.v3BI7PGM001952@chez.mckusick.com> References: <201704111807.v3BI7PGM001952@chez.mckusick.com> From: Maxim Sobolev Date: Tue, 11 Apr 2017 11:23:57 -0700 X-Google-Sender-Auth: CImaKWRmncEBjyxNALMPehW2Jl8 Message-ID: Subject: Re: mksnap_ffs(8) is not working while chrooted To: Kirk McKusick Cc: FreeBSD Filesystems 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: Tue, 11 Apr 2017 18:23:58 -0000 Kirk, what you are saying in not applying in our case. The whole FS is mounted *inside* the chroot. The reason why we are trying to use mksnap_ffs is to take a clean snapshot to make a compressed version of it without the need to forcefully zero out free space. So it looks like the following: parent# chroot /mnt/chroot /bin/sh chroot# truncate /tmp/diskimage chroot# mdconfig -a -f /tmp/diskimage md0 chroot# newfs md0 chroot# mount /dev/md0 /mnt [...do stuff with /mnt...] chroot# mksnap_ffs /mnt/snap mksnap_ffs: No such file or directory Perhaps, to work around your concern is to add some flag for the statfs(1) to normalize f_mntonname for use inside chroot then? I have not tested it here, but I believe that if I'd strip "/mnt/chroot" prefix inside mksnap_ffs(8) that would work in our scenario just fine. -Max On Tue, Apr 11, 2017 at 11:07 AM, Kirk McKusick wrote: > > From: Maxim Sobolev > > Date: Tue, 11 Apr 2017 10:40:58 -0700 > > Subject: mksnap_ffs(8) is not working while chrooted > > To: Kirk McKusick , > > FreeBSD Filesystems > > > > Hi Kirk et al, > > > > I've stumbled upon problem that it is impossible to use mksnap_ffs(8) > while > > in the chrooted environment. Other utilities that manipulate fs'es (i.e. > > mount(8) / umount(8)) work just fine. Quick glance through the code shows > > that the problem stems from the fact that mksnap_ffs uses f_mntonname > > returned by the statfs(2) system call to fill fspath parameter for the > > nmount call. And the statfs() returns f_mntonname path outside chroot. As > > far as I can see, there are two options to address this issue. > > > > 1. Adjust statfs(2) system call to substract chroot prefix while > > returning f_mntonname. Similar to what prison_enforce_statfs() function > > does for jails. > > > > 2. Enhance nmount(2) to allow taking FSID in place of mount path to do > > resolution using existing flag MNT_BYFSID and adjust mksnap_ffs to use > that > > instead. This is what umount(8) does to work around the problem. > > > > Which of two approaches would be preferred solution if any? The second > one > > seems a bit simpler to me. Please advise. Thanks! > > > > -Max > > It is not secure to allow mksnap_ffs(8) to work inside a jail. The issue > is that mksnap_ffs takes a snapshot of the entire filesystem. Based on the > way that snapshots work in FFS, it is not possible to snapshot only the > part of the filesystem that is in the jail. Thus, if you take a snapshot > of the entire filesystem and then mount it inside the jail, you will > expose parts of the filesystem from outside of the jail to the jail. > As such, you should only be able to snapshot a filesystem if it is > entirely contained within the jail. > > If snapshots within jails are important to you, I recommend that you use > ZFS which allows you to create per-jail filesystems which you can then > snapshot. > > Kirk McKusick > > From owner-freebsd-fs@freebsd.org Tue Apr 11 18:55:23 2017 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 3755CD3AC58 for ; Tue, 11 Apr 2017 18:55:23 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 0768F1533 for ; Tue, 11 Apr 2017 18:55:22 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-io0-x22b.google.com with SMTP id r16so12551385ioi.2 for ; Tue, 11 Apr 2017 11:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tTSwljkJdLDxNUgZJ4RH1Hkv4pveTPf1UYrUY2CHF38=; b=YJ7q1lIMrCF9ja17nS9D/IWUmwPH0p8bZtrZD0SnP0Vb5Mtwy60ErLpGjXd0dIWV2d QWod7ByFy1m4QS9jhvjBkfYyAZFGT/rLFAL+hBqTCMOYH0gczzoWNaRp0VsnzxVIFngb 5Q4I8CS6YcvPd9OYlwvylhFpfgPZeWCRC5p4Z3iB/YFXkDyPBXXn3ea9UfDZrIB0qlM8 C8mS9wz+j2VSr5o8raRBXlXNyK7Lit92x559NwIUFy9uTemJV1LMvMdzje6KWfXPwrVG wYaI3X3Dc1X/2MYLmwkJNTeZFhaLNiQUe4Zn0wF1S1JvOmjDvIZw4XJkTtJPcXQWr8Oc y/pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tTSwljkJdLDxNUgZJ4RH1Hkv4pveTPf1UYrUY2CHF38=; b=n0IubCX6NyTt0A6iX8Vcnk/EbmUcfK2XdaIfFieM5FDmB/TtDNKUmAoWiEfqyfF1+o bHUF266tdrUn0tUVZtDNN1jZmQ1FKhhSyFGT8NQVkdg1b3yy3AQhtQS7lXRAJnfeLu9P L/9crI1ngBQ29sUCrRhAU2jI3q2VECye5DpyboILoh5YNjth08GmaD9+SHZ7TF5ycxQk lexXJZwPpUGcKA0tP2+pqvEduK6U3x5l3Q24hno3fX6iqyTsUOjkEJoto8bM6oonlQTo 8Zb249+Ru2dKlXINU/D8UrjdG4mdCVcaGoC1JX6lpMHWRAJhgI8Os3+aDhFcP/w2XPjH HzXA== X-Gm-Message-State: AN3rC/5o1bUPG1ITQi37YRdT52vdaab029N9J8nMs6eGHwVM191CmYC5 Do8rTN90IjLBCxkSmY6umjvrj5iUvp4lwDw= X-Received: by 10.36.74.196 with SMTP id k187mr18574948itb.49.1491936922059; Tue, 11 Apr 2017 11:55:22 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.112.210 with HTTP; Tue, 11 Apr 2017 11:55:21 -0700 (PDT) In-Reply-To: References: <201704111807.v3BI7PGM001952@chez.mckusick.com> From: Maxim Sobolev Date: Tue, 11 Apr 2017 11:55:21 -0700 X-Google-Sender-Auth: dxHY2yMiFuZeXASrtbfVRgr9bgY Message-ID: Subject: Re: mksnap_ffs(8) is not working while chrooted To: Kirk McKusick Cc: FreeBSD Filesystems 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: Tue, 11 Apr 2017 18:55:23 -0000 Kirk, yes, indeed, it works just fine if I chop out the chroot prefix manually here: [/builder.trunk/usr/src/sbin/mksnap_ffs]$ sudo chroot /builder.trunk sh # truncate -s 100m /tmp/fsimage # mdconfig -a -f /tmp/fsimage md0 # newfs /dev/md0 /dev/md0: 100.0MB (204800 sectors) block size 32768, fragment size 4096 using 4 cylinder groups of 25.03MB, 801 blks, 3328 inodes. super-block backups (for fsck_ffs -b #) at: 192, 51456, 102720, 153984 # mount /dev/md0 /mnt # /usr/src/sbin/mksnap_ffs/mksnap_ffs /mnt/mysnap # ls -l /mnt/mysnap -r--r----- 1 root operator 104857672 Apr 11 18:42 /mnt/mysnap # ^D [/builder.trunk/usr/src/sbin/mksnap_ffs]$ git diff diff --git a/sbin/mksnap_ffs/mksnap_ffs.c b/sbin/mksnap_ffs/mksnap_ffs.c index efd9c6b33..b1fba5e16 100644 --- a/sbin/mksnap_ffs/mksnap_ffs.c +++ b/sbin/mksnap_ffs/mksnap_ffs.c @@ -116,7 +116,7 @@ main(int argc, char **argv) iovlen = 0; build_iovec(&iov, &iovlen, "fstype", "ffs", 4); build_iovec(&iov, &iovlen, "from", snapname, (size_t)-1); - build_iovec(&iov, &iovlen, "fspath", stfsbuf.f_mntonname, (size_t)-1); + build_iovec(&iov, &iovlen, "fspath", stfsbuf.f_mntonname + 14, (size_t)-1); build_iovec(&iov, &iovlen, "errmsg", errmsg, sizeof(errmsg)); build_iovec(&iov, &iovlen, "update", NULL, 0); build_iovec(&iov, &iovlen, "snapshot", NULL, 0); So my point is that by making this scenario working OOB I don't think we would add any new security issue. This already works if you pass proper path into the nmount(2) and the mount path is inside chroot. In principle I can possibly do some clever trick on the userland only to strip offending prefix f_mntonname here component by component until we can locate the mount dir, but it's likely to be somewhat fuzzy and clearly not suitable for the basesrc repo. -Max On Tue, Apr 11, 2017 at 11:23 AM, Maxim Sobolev wrote: > Kirk, what you are saying in not applying in our case. The whole FS is > mounted *inside* the chroot. The reason why we are trying to use mksnap_ffs > is to take a clean snapshot to make a compressed version of it without the > need to forcefully zero out free space. > > So it looks like the following: > > parent# chroot /mnt/chroot /bin/sh > chroot# truncate /tmp/diskimage > chroot# mdconfig -a -f /tmp/diskimage > md0 > chroot# newfs md0 > chroot# mount /dev/md0 /mnt > [...do stuff with /mnt...] > chroot# mksnap_ffs /mnt/snap > mksnap_ffs: No such file or directory > > Perhaps, to work around your concern is to add some flag for the statfs(1) > to normalize f_mntonname for use inside chroot then? I have not tested it > here, but I believe that if I'd strip "/mnt/chroot" prefix inside > mksnap_ffs(8) that would work in our scenario just fine. > > -Max > > On Tue, Apr 11, 2017 at 11:07 AM, Kirk McKusick > wrote: > >> > From: Maxim Sobolev >> > Date: Tue, 11 Apr 2017 10:40:58 -0700 >> > Subject: mksnap_ffs(8) is not working while chrooted >> > To: Kirk McKusick , >> > FreeBSD Filesystems >> > >> > Hi Kirk et al, >> > >> > I've stumbled upon problem that it is impossible to use mksnap_ffs(8) >> while >> > in the chrooted environment. Other utilities that manipulate fs'es (i.e. >> > mount(8) / umount(8)) work just fine. Quick glance through the code >> shows >> > that the problem stems from the fact that mksnap_ffs uses f_mntonname >> > returned by the statfs(2) system call to fill fspath parameter for the >> > nmount call. And the statfs() returns f_mntonname path outside chroot. >> As >> > far as I can see, there are two options to address this issue. >> > >> > 1. Adjust statfs(2) system call to substract chroot prefix while >> > returning f_mntonname. Similar to what prison_enforce_statfs() function >> > does for jails. >> > >> > 2. Enhance nmount(2) to allow taking FSID in place of mount path to do >> > resolution using existing flag MNT_BYFSID and adjust mksnap_ffs to use >> that >> > instead. This is what umount(8) does to work around the problem. >> > >> > Which of two approaches would be preferred solution if any? The second >> one >> > seems a bit simpler to me. Please advise. Thanks! >> > >> > -Max >> >> It is not secure to allow mksnap_ffs(8) to work inside a jail. The issue >> is that mksnap_ffs takes a snapshot of the entire filesystem. Based on the >> way that snapshots work in FFS, it is not possible to snapshot only the >> part of the filesystem that is in the jail. Thus, if you take a snapshot >> of the entire filesystem and then mount it inside the jail, you will >> expose parts of the filesystem from outside of the jail to the jail. >> As such, you should only be able to snapshot a filesystem if it is >> entirely contained within the jail. >> >> If snapshots within jails are important to you, I recommend that you use >> ZFS which allows you to create per-jail filesystems which you can then >> snapshot. >> >> Kirk McKusick >> >> > From owner-freebsd-fs@freebsd.org Tue Apr 11 20:22:09 2017 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 C71D9D3AD5E for ; Tue, 11 Apr 2017 20:22:09 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8684E638 for ; Tue, 11 Apr 2017 20:22:09 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-io0-x22c.google.com with SMTP id r16so15451359ioi.2 for ; Tue, 11 Apr 2017 13:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XhERijJ19H9pUjdYci7d7OMcYP2tTYZRVba7Dfv0y0s=; b=DrpyDuWIrfbRie8d8V8ar49nSkM2XMHzC94iGaJloxYOIFJPqJLhq55kDwz+TiMVkn PM4oIPBuzK+T41nM414CTSX+D4s9w+jrrFDC30kq76KOzr0th8cJSzwX2pRXL86TMeME zUPKn7tOHE2XhNF8eBJohvQis55mOmo/INJeTMhjgE0KcfQNUA7Gtz/OcZsKGgVki2og M0afpIJsBtjbYsz2Ld1pktjJxr7yVVsBfh0+Kn9UBZucYxNfUI663aiZFLYlGFOylimu B59EB1x3G6DHqyK4eI5zjp/HUuZ95C1dZDQAlxQpncwflkgCbdDRFQhH7piYVVHIyD0a HO5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XhERijJ19H9pUjdYci7d7OMcYP2tTYZRVba7Dfv0y0s=; b=A1V3/IMmuu7R0SAj86qqCCK4ydttl673Sdnr6e1IMBuv7+iE7uGszydj/wXJeXei5n cl/0cHZ3BlYdecxOikjPwUAcWh8Y0tqGIgdbXpsqx9emlZe1LXuyWXRnd+PvNPzqTJHZ osobNy2VAX6EM0VsUv1omiaJub/DnXRuUAiUPdKv7zK+wofHMIh0lhGjL9t6NEzkBW8a UEGQ6TBw65BASS5SR9NOTlqYznOPoJ/j9XUDOYjR7+nSAO4STzb/OcpUjRryt41NyIiD BEMJoauxcAjEYO+ucPyS6oQitonfBRzuuitucknOljs8w9zt637c7wbgFeXkHlo8AO0i Ehbw== X-Gm-Message-State: AFeK/H35cLuu6may9Vuzb6W8pI5hkkMjpR+ZG64DdCD5UDqMIm0optYfz7pbGPn+7ocGbeS9fbc2RD+HpJQa85wt X-Received: by 10.107.171.67 with SMTP id u64mr57477142ioe.102.1491942128752; Tue, 11 Apr 2017 13:22:08 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.112.210 with HTTP; Tue, 11 Apr 2017 13:22:08 -0700 (PDT) In-Reply-To: References: <201704111807.v3BI7PGM001952@chez.mckusick.com> From: Maxim Sobolev Date: Tue, 11 Apr 2017 13:22:08 -0700 X-Google-Sender-Auth: vdYAvcJNgoiuu-tUdLqL6jMuAXg Message-ID: Subject: Re: mksnap_ffs(8) is not working while chrooted To: Kirk McKusick Cc: FreeBSD Filesystems Content-Type: multipart/mixed; boundary=94eb2c059e149cc4b8054ce9d80d 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, 11 Apr 2017 20:22:09 -0000 --94eb2c059e149cc4b8054ce9d80d Content-Type: text/plain; charset=UTF-8 Kirk, actually it turns out this is not too difficult to work around this issue completely in userland. Please see the patch attached, should be relatively bulletproof as it actually verifies fsid of whatever it finds with the fsid of the target FS. Please let me know if there are any objections to include it into the base system. Thanks! -Maxim On Tue, Apr 11, 2017 at 11:55 AM, Maxim Sobolev wrote: > Kirk, yes, indeed, it works just fine if I chop out the chroot prefix > manually here: > > [/builder.trunk/usr/src/sbin/mksnap_ffs]$ sudo chroot /builder.trunk sh > # truncate -s 100m /tmp/fsimage > # mdconfig -a -f /tmp/fsimage > md0 > # newfs /dev/md0 > /dev/md0: 100.0MB (204800 sectors) block size 32768, fragment size 4096 > using 4 cylinder groups of 25.03MB, 801 blks, 3328 inodes. > super-block backups (for fsck_ffs -b #) at: > 192, 51456, 102720, 153984 > # mount /dev/md0 /mnt > # /usr/src/sbin/mksnap_ffs/mksnap_ffs /mnt/mysnap > # ls -l /mnt/mysnap > -r--r----- 1 root operator 104857672 Apr 11 18:42 /mnt/mysnap > # ^D > [/builder.trunk/usr/src/sbin/mksnap_ffs]$ git diff > diff --git a/sbin/mksnap_ffs/mksnap_ffs.c b/sbin/mksnap_ffs/mksnap_ffs.c > index efd9c6b33..b1fba5e16 100644 > --- a/sbin/mksnap_ffs/mksnap_ffs.c > +++ b/sbin/mksnap_ffs/mksnap_ffs.c > @@ -116,7 +116,7 @@ main(int argc, char **argv) > iovlen = 0; > build_iovec(&iov, &iovlen, "fstype", "ffs", 4); > build_iovec(&iov, &iovlen, "from", snapname, (size_t)-1); > - build_iovec(&iov, &iovlen, "fspath", stfsbuf.f_mntonname, > (size_t)-1); > + build_iovec(&iov, &iovlen, "fspath", stfsbuf.f_mntonname + 14, > (size_t)-1); > build_iovec(&iov, &iovlen, "errmsg", errmsg, sizeof(errmsg)); > build_iovec(&iov, &iovlen, "update", NULL, 0); > build_iovec(&iov, &iovlen, "snapshot", NULL, 0); > > So my point is that by making this scenario working OOB I don't think we > would add any new security issue. This already works if you pass proper > path into the nmount(2) and the mount path is inside chroot. In principle I > can possibly do some clever trick on the userland only to strip offending > prefix f_mntonname here component by component until we can locate the > mount dir, but it's likely to be somewhat fuzzy and clearly not suitable > for the basesrc repo. > > -Max > > On Tue, Apr 11, 2017 at 11:23 AM, Maxim Sobolev > wrote: > >> Kirk, what you are saying in not applying in our case. The whole FS is >> mounted *inside* the chroot. The reason why we are trying to use mksnap_ffs >> is to take a clean snapshot to make a compressed version of it without the >> need to forcefully zero out free space. >> >> So it looks like the following: >> >> parent# chroot /mnt/chroot /bin/sh >> chroot# truncate /tmp/diskimage >> chroot# mdconfig -a -f /tmp/diskimage >> md0 >> chroot# newfs md0 >> chroot# mount /dev/md0 /mnt >> [...do stuff with /mnt...] >> chroot# mksnap_ffs /mnt/snap >> mksnap_ffs: No such file or directory >> >> Perhaps, to work around your concern is to add some flag for the >> statfs(1) to normalize f_mntonname for use inside chroot then? I have >> not tested it here, but I believe that if I'd strip "/mnt/chroot" prefix >> inside mksnap_ffs(8) that would work in our scenario just fine. >> >> -Max >> >> On Tue, Apr 11, 2017 at 11:07 AM, Kirk McKusick >> wrote: >> >>> > From: Maxim Sobolev >>> > Date: Tue, 11 Apr 2017 10:40:58 -0700 >>> > Subject: mksnap_ffs(8) is not working while chrooted >>> > To: Kirk McKusick , >>> > FreeBSD Filesystems >>> > >>> > Hi Kirk et al, >>> > >>> > I've stumbled upon problem that it is impossible to use mksnap_ffs(8) >>> while >>> > in the chrooted environment. Other utilities that manipulate fs'es >>> (i.e. >>> > mount(8) / umount(8)) work just fine. Quick glance through the code >>> shows >>> > that the problem stems from the fact that mksnap_ffs uses f_mntonname >>> > returned by the statfs(2) system call to fill fspath parameter for the >>> > nmount call. And the statfs() returns f_mntonname path outside chroot. >>> As >>> > far as I can see, there are two options to address this issue. >>> > >>> > 1. Adjust statfs(2) system call to substract chroot prefix while >>> > returning f_mntonname. Similar to what prison_enforce_statfs() function >>> > does for jails. >>> > >>> > 2. Enhance nmount(2) to allow taking FSID in place of mount path to do >>> > resolution using existing flag MNT_BYFSID and adjust mksnap_ffs to use >>> that >>> > instead. This is what umount(8) does to work around the problem. >>> > >>> > Which of two approaches would be preferred solution if any? The second >>> one >>> > seems a bit simpler to me. Please advise. Thanks! >>> > >>> > -Max >>> >>> It is not secure to allow mksnap_ffs(8) to work inside a jail. The issue >>> is that mksnap_ffs takes a snapshot of the entire filesystem. Based on >>> the >>> way that snapshots work in FFS, it is not possible to snapshot only the >>> part of the filesystem that is in the jail. Thus, if you take a snapshot >>> of the entire filesystem and then mount it inside the jail, you will >>> expose parts of the filesystem from outside of the jail to the jail. >>> As such, you should only be able to snapshot a filesystem if it is >>> entirely contained within the jail. >>> >>> If snapshots within jails are important to you, I recommend that you use >>> ZFS which allows you to create per-jail filesystems which you can then >>> snapshot. >>> >>> Kirk McKusick >>> >>> >> > --94eb2c059e149cc4b8054ce9d80d Content-Type: text/plain; charset=US-ASCII; name="mksnap_ffs.diff" Content-Disposition: attachment; filename="mksnap_ffs.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j1dzs84g0 ZGlmZiAtLWdpdCBhL3NiaW4vbWtzbmFwX2Zmcy9ta3NuYXBfZmZzLmMgYi9zYmluL21rc25hcF9m ZnMvbWtzbmFwX2Zmcy5jCmluZGV4IGVmZDljNmIzMy4uYjAzOWZhZGQyIDEwMDY0NAotLS0gYS9z YmluL21rc25hcF9mZnMvbWtzbmFwX2Zmcy5jCisrKyBiL3NiaW4vbWtzbmFwX2Zmcy9ta3NuYXBf ZmZzLmMKQEAgLTU4LDYgKzU4LDMzIEBAIHVzYWdlKHZvaWQpCiAJZXJyeChFWF9VU0FHRSwgInVz YWdlOiBta3NuYXBfZmZzIHNuYXBzaG90X25hbWUiKTsKIH0KIAorc3RhdGljIGludAoraXNkaXIo Y29uc3QgY2hhciAqcGF0aCkKK3sKKwlzdHJ1Y3Qgc3RhdCBzdGJ1ZjsKKworCWlmIChzdGF0KHBh dGgsICZzdGJ1ZikgPCAwKQorCQlyZXR1cm4gKC0xKTsKKyAgICAgICAgaWYgKCFTX0lTRElSKHN0 YnVmLnN0X21vZGUpKQorCQlyZXR1cm4gKDApOworCXJldHVybiAoMSk7Cit9CisKK3N0YXRpYyBp bnQKK2lzc2FtZWZzKGNvbnN0IGNoYXIgKnBhdGgsIHN0cnVjdCBzdGF0ZnMgKnN0ZnNwKQorewor CXN0cnVjdCBzdGF0ZnMgc3Rmc2J1ZjsKKworCWlmIChpc2RpcihwYXRoKSAhPSAxKQorCQlyZXR1 cm4gKC0xKTsKKwlpZiAoc3RhdGZzKHBhdGgsICZzdGZzYnVmKSA8IDApCisJCXJldHVybiAoLTEp OworCWlmICgoc3Rmc2J1Zi5mX2ZzaWQudmFsWzBdICE9IHN0ZnNwLT5mX2ZzaWQudmFsWzBdKSB8 fAorCSAgICAoc3Rmc2J1Zi5mX2ZzaWQudmFsWzFdICE9IHN0ZnNwLT5mX2ZzaWQudmFsWzFdKSkK KwkJcmV0dXJuICgwKTsKKwlyZXR1cm4gKDEpOworfQorCiBpbnQKIG1haW4oaW50IGFyZ2MsIGNo YXIgKiphcmd2KQogewpAQCAtOTYsMTYgKzEyMywzMyBAQCBtYWluKGludCBhcmdjLCBjaGFyICoq YXJndikKIAl9CiAJaWYgKHN0YXRmcyhwYXRoLCAmc3Rmc2J1ZikgPCAwKQogCQllcnIoMSwgIiVz IiwgcGF0aCk7Ci0JaWYgKHN0YXQocGF0aCwgJnN0YnVmKSA8IDApCisJc3dpdGNoIChpc2Rpcihw YXRoKSkgeworCWNhc2UgLTE6CiAJCWVycigxLCAiJXMiLCBwYXRoKTsKLQlpZiAoIVNfSVNESVIo c3RidWYuc3RfbW9kZSkpCisJY2FzZSAwOgogCQllcnJ4KDEsICIlczogTm90IGEgZGlyZWN0b3J5 IiwgcGF0aCk7CisJZGVmYXVsdDoKKwkJYnJlYWs7CisJfQogCWlmIChhY2Nlc3MocGF0aCwgV19P SykgPCAwKQogCQllcnIoMSwgIkxhY2sgd3JpdGUgcGVybWlzc2lvbiBpbiAlcyIsIHBhdGgpOwog CWlmICgoc3RidWYuc3RfbW9kZSAmIFNfSVNUWFQpICYmIHN0YnVmLnN0X3VpZCAhPSBnZXR1aWQo KSkKIAkJZXJyeCgxLCAiTGFjayB3cml0ZSBwZXJtaXNzaW9uIGluICVzOiBTdGlja3kgYml0IHNl dCIsIHBhdGgpOwogCiAJLyoKKwkgKiBXb3JrIGFyb3VuZCBhbiBpc3N1ZSB3aGVuIG1rc25hcF9m ZnMgaXMgc3RhcnRlZCBpbiBjaHJvb3QnZWQKKwkgKiBlbnZpcm9ubWVudCBhbmQgZl9tbnRvbm5h bWUgY29udGFpbnMgYWJzb2x1dGUgcGF0aCB3aXRoaW4KKwkgKiByZWFsIHJvb3QuCisJICovCisJ Zm9yIChjcCA9IHN0ZnNidWYuZl9tbnRvbm5hbWU7IGlzc2FtZWZzKGNwLCAmc3Rmc2J1ZikgIT0g MTsKKwkgICAgY3AgPSBzdHJjaHJudWwoY3AgKyAxLCAnLycpKSB7CisJCWlmIChjcFswXSA9PSAn XDAnKQorCQkJZXJyeCgxLCAiJXM6IE5vdCBhIG1vdW50IHBvaW50Iiwgc3Rmc2J1Zi5mX21udG9u bmFtZSk7CisJfQorCWlmIChjcCAhPSBzdGZzYnVmLmZfbW50b25uYW1lKQorCQlzdHJsY3B5KHN0 ZnNidWYuZl9tbnRvbm5hbWUsIGNwLCBzaXplb2Yoc3Rmc2J1Zi5mX21udG9ubmFtZSkpOworCisJ LyoKIAkgKiBIYXZpbmcgdmVyaWZpZWQgYWNjZXNzIHRvIHRoZSBkaXJlY3RvcnkgaW4gd2hpY2gg dGhlCiAJICogc25hcHNob3QgaXMgdG8gYmUgYnVpbHQsIHByb2NlZWQgd2l0aCBjcmVhdGluZyBp dC4KIAkgKi8K --94eb2c059e149cc4b8054ce9d80d-- From owner-freebsd-fs@freebsd.org Tue Apr 11 20:32:16 2017 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 1C402D3A11B for ; Tue, 11 Apr 2017 20:32:16 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) (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 E1FCCD86; Tue, 11 Apr 2017 20:32:15 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id v3BKWwBn005429; Tue, 11 Apr 2017 13:32:58 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201704112032.v3BKWwBn005429@chez.mckusick.com> From: Kirk McKusick To: Maxim Sobolev Subject: Re: mksnap_ffs(8) is not working while chrooted cc: FreeBSD Filesystems In-reply-to: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5427.1491942778.1@chez.mckusick.com> Date: Tue, 11 Apr 2017 13:32:58 -0700 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, 11 Apr 2017 20:32:16 -0000 > From: Maxim Sobolev > Date: Tue, 11 Apr 2017 13:22:08 -0700 > Subject: Re: mksnap_ffs(8) is not working while chrooted > To: Kirk McKusick > > Kirk, actually it turns out this is not too difficult to work around this > issue completely in userland. Please see the patch attached, should be > relatively bulletproof as it actually verifies fsid of whatever it finds > with the fsid of the target FS. Please let me know if there are any > objections to include it into the base system. > > Thanks! > -Maxim With your change to verify the matching fsid's, I am fine with your putting this change into the base system. Kirk McKusick From owner-freebsd-fs@freebsd.org Wed Apr 12 18:01:12 2017 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 04C78D3B2B5; Wed, 12 Apr 2017 18:01:12 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4529DB26; Wed, 12 Apr 2017 18:01:11 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from [192.168.243.2] ([192.168.243.2]) (authenticated bits=0) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPSA id v3CI15bD009360 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 12 Apr 2017 23:01:06 +0500 (YEKT) (envelope-from emz@norma.perm.ru) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=norma.perm.ru; s=key; t=1492020066; bh=W43TYZL3QHw6Gam1ePqA9lwtlPS106SGe3hjGS6htkk=; h=To:From:Subject:Date; b=cR1v64/5F+mQLyJaTjoThqRJlISXGcsZQe0Y8Er9tk2DKSftnlhoiw8o63dUDhiz6 MN3iMvpLveI1hsQ7LarbfFr12LYQOmeYzA8cR2c9bJXLjKZ7zSfQx8NA1JYWxZ4rgP fBP0bd8wQwKM2NhtP02bFSQnGDjVr7mm1F8uA4vM= To: freebsd-stable@FreeBSD.org, FreeBSD FS From: "Eugene M. Zheganin" Subject: zpool list show nonsense on raidz pools, at least it looks like it for me Message-ID: <71ef8400-94ec-1f59-3b2b-bb576ad65b89@norma.perm.ru> Date: Wed, 12 Apr 2017 23:01:10 +0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.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: Wed, 12 Apr 2017 18:01:12 -0000 Hi, It's not my first letter where I fail to understand the space usage from zfs utilities, and in previous ones I was kind of convinced that I just read it wrong, but not this time I guess. See for yourself: [emz@san01:~]> zpool list data NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT data 17,4T 7,72T 9,66T - 46% 44% 1.00x ONLINE - Here' as I understand it, zpool says that less than a half of the pool is used. As far as I know this is very complicated when it comes to the radiz pools. Let's see: [emz@san01:~]> zfs list -t all data NAME USED AVAIL REFER MOUNTPOINT data 13,3T 186G 27,2K /data So, if we won't investigate further, it looks like that only 186G is free. Spoiling - this is the real free space amount, because I've just managed to free 160 gigs of data, and I really know I was short on space when sending 30 Gb dataset, because zfs was saying "Not enough free space". So, let's investigate further: [emz@san01:~]> zfs list -t all | more NAME USED AVAIL REFER MOUNTPOINT data 13,3T 186G 27,2K /data data/esx 5,23T 186G 27,2K /data/esx data/esx/boot-esx01 8,25G 193G 561M - data/esx/boot-esx02 8,25G 193G 561M - data/esx/boot-esx03 8,25G 193G 561M - data/esx/boot-esx04 8,25G 193G 561M - data/esx/boot-esx05 8,25G 193G 561M - data/esx/boot-esx06 8,25G 193G 561M - data/esx/boot-esx07 8,25G 193G 962M - data/esx/boot-esx08 8,25G 193G 562M - data/esx/boot-esx09 8,25G 193G 562M - data/esx/boot-esx10 8,25G 193G 595M - data/esx/boot-esx11 8,25G 193G 539M - data/esx/boot-esx12 8,25G 193G 539M - data/esx/boot-esx13 8,25G 193G 539M - data/esx/boot-esx14 8,25G 193G 539M - data/esx/boot-esx15 8,25G 193G 539M - data/esx/boot-esx16 8,25G 193G 541M - data/esx/boot-esx17 8,25G 193G 540M - data/esx/boot-esx18 8,25G 193G 539M - data/esx/boot-esx19 8,25G 193G 542M - data/esx/boot-esx20 8,25G 194G 12,8K - data/esx/boot-esx21 8,25G 194G 12,8K - data/esx/boot-esx22 8,25G 193G 913M - data/esx/boot-esx23 8,25G 193G 558M - data/esx/boot-esx24 8,25G 194G 12,8K - data/esx/boot-esx25 8,25G 194G 12,8K - data/esx/boot-esx26 8,25G 194G 12,8K - data/esx/shared 5,02T 2,59T 2,61T - data/reference 6,74T 4,17T 2,73T - data/reference@ver7_214 127M - 2,73T - data/reference@ver2_739 12,8M - 2,73T - data/reference@ver2_740 5,80M - 2,73T - data/reference@ver2_741 4,55M - 2,73T - data/reference@ver2_742 993K - 2,73T - data/reference-ver2_739-worker100 1,64G 186G 2,73T - data/reference-ver2_739-worker101 254M 186G 2,73T - data/reference-ver2_739-worker102 566K 186G 2,73T - data/reference-ver2_739-worker103 260M 186G 2,73T - data/reference-ver2_739-worker104 8,74G 186G 2,73T - data/reference-ver2_739-worker105 4,19G 186G 2,73T - data/reference-ver2_739-worker106 1,72G 186G 2,73T - data/reference-ver2_739-worker107 282M 186G 2,73T - data/reference-ver2_739-worker108 1,27M 186G 2,73T - data/reference-ver2_739-worker109 8,74G 186G 2,73T - data/reference-ver2_739-worker110 8,74G 186G 2,73T - data/reference-ver2_739-worker111 8,74G 186G 2,73T - data/reference-ver2_739-worker112 8,74G 186G 2,73T - data/reference-ver2_739-worker113 838K 186G 2,73T - data/reference-ver2_739-worker114 8,74G 186G 2,73T - data/reference-ver2_739-worker115 8,74G 186G 2,73T - data/reference-ver2_739-worker116 8,74G 186G 2,73T - data/reference-ver2_739-worker117 8,74G 186G 2,73T - data/reference-ver2_739-worker118 8,74G 186G 2,73T - data/reference-ver2_739-worker119 8,74G 186G 2,73T - data/reference-ver2_739-worker120 8,74G 186G 2,73T - data/reference-ver2_739-worker121 8,74G 186G 2,73T - data/reference-ver2_739-worker122 8,74G 186G 2,73T - data/reference-ver2_739-worker123 8,74G 186G 2,73T - data/reference-ver2_739-worker124 8,74G 186G 2,73T - data/reference-ver2_739-worker125 8,74G 186G 2,73T - data/reference-ver2_739-worker126 8,74G 186G 2,73T - data/reference-ver2_739-worker127 8,74G 186G 2,73T - data/reference-ver2_739-worker128 8,74G 186G 2,73T - data/reference-ver2_739-worker129 8,74G 186G 2,73T - data/reference-ver2_739-worker130 8,74G 186G 2,73T - data/reference-ver2_739-worker131 8,74G 186G 2,73T - data/reference-ver2_739-worker132 8,74G 186G 2,73T - data/reference-ver2_739-worker133 8,74G 186G 2,73T - data/reference-ver2_739-worker134 8,74G 186G 2,73T - data/reference-ver2_739-worker135 8,74G 186G 2,73T - data/reference-ver2_739-worker136 8,74G 186G 2,73T - data/reference-ver2_739-worker137 8,74G 186G 2,73T - data/reference-ver2_739-worker138 8,74G 186G 2,73T - data/reference-ver2_739-worker139 8,74G 186G 2,73T - data/reference-ver2_739-worker140 8,74G 186G 2,73T - data/reference-ver2_739-worker141 8,74G 186G 2,73T - data/reference-ver2_739-worker142 8,74G 186G 2,73T - data/reference-ver2_739-worker143 8,73G 186G 2,73T - data/reference-ver2_739-worker144 9,16G 186G 2,73T - data/reference-ver2_739-worker145 8,74G 186G 2,73T - data/reference-ver2_739-worker146 8,74G 186G 2,73T - data/reference-ver2_739-worker147 8,74G 186G 2,73T - data/reference-ver2_739-worker148 8,74G 186G 2,73T - data/reference-ver2_739-worker149 8,74G 186G 2,73T - data/reference-ver2_739-worker150 8,74G 186G 2,73T - data/reference-ver2_739-worker151 8,74G 186G 2,73T - data/reference-ver2_739-worker152 8,74G 186G 2,73T - data/reference-ver2_739-worker53 385K 186G 2,73T - data/reference-ver2_739-worker58 9,49M 186G 2,73T - data/reference-ver2_739-worker81 8,20G 186G 2,73T - data/reference-ver2_739-worker82 7,64G 186G 2,73T - data/reference-ver2_739-worker83 6,84G 186G 2,73T - data/reference-ver2_739-worker84 5,95G 186G 2,73T - data/reference-ver2_739-worker85 5,09G 186G 2,73T - data/reference-ver2_739-worker86 3,76G 186G 2,73T - data/reference-ver2_739-worker87 4,06G 186G 2,73T - data/reference-ver2_739-worker88 1,92G 186G 2,73T - data/reference-ver2_739-worker89 6,83G 186G 2,73T - data/reference-ver2_739-worker90 6,55G 186G 2,73T - data/reference-ver2_739-worker91 5,25G 186G 2,73T - data/reference-ver2_739-worker92 4,18G 186G 2,73T - data/reference-ver2_739-worker93 3,18G 186G 2,73T - data/reference-ver2_739-worker94 983M 186G 2,73T - data/reference-ver2_739-worker95 525M 186G 2,73T - data/reference-ver2_739-worker96 650M 186G 2,73T - data/reference-ver2_739-worker97 5,78G 186G 2,73T - data/reference-ver2_739-worker98 4,81G 186G 2,73T - data/reference-ver2_739-worker99 4,93G 186G 2,73T - data/reference-ver2_740-worker56 361K 186G 2,73T - data/reference-ver2_741-worker74 3,98M 186G 2,73T - data/reference-ver2_742-worker02 934K 186G 2,73T - data/reference-ver2_742-worker03 935K 186G 2,73T - data/reference-ver2_742-worker04 935K 186G 2,73T - data/reference-ver2_742-worker05 935K 186G 2,73T - data/reference-ver2_742-worker06 935K 186G 2,73T - data/reference-ver2_742-worker08 934K 186G 2,73T - data/reference-ver2_742-worker09 15,9M 186G 2,73T - data/reference-ver2_742-worker10 16,2M 186G 2,73T - data/reference-ver2_742-worker11 15,4M 186G 2,73T - data/reference-ver2_742-worker12 935K 186G 2,73T - data/reference-ver2_742-worker13 15,9M 186G 2,73T - data/reference-ver2_742-worker14 935K 186G 2,73T - data/reference-ver2_742-worker15 15,5M 186G 2,73T - data/reference-ver2_742-worker16 934K 186G 2,73T - data/reference-ver2_742-worker17 934K 186G 2,73T - data/reference-ver2_742-worker18 935K 186G 2,73T - data/reference-ver2_742-worker19 531M 186G 2,73T - data/reference-ver2_742-worker20 935K 186G 2,73T - data/reference-ver2_742-worker21 935K 186G 2,73T - data/reference-ver2_742-worker22 5,27G 186G 2,73T - data/reference-ver2_742-worker23 934K 186G 2,73T - data/reference-ver2_742-worker24 5,27G 186G 2,73T - data/reference-ver2_742-worker25 934K 186G 2,73T - data/reference-ver2_742-worker26 934K 186G 2,73T - data/reference-ver2_742-worker27 15,8M 186G 2,73T - data/reference-ver2_742-worker28 935K 186G 2,73T - data/reference-ver2_742-worker29 934K 186G 2,73T - data/reference-ver2_742-worker30 934K 186G 2,73T - data/reference-ver2_742-worker31 934K 186G 2,73T - data/reference-ver2_742-worker32 444M 186G 2,73T - data/reference-ver2_742-worker33 935K 186G 2,73T - data/reference-ver2_742-worker34 15,9M 186G 2,73T - data/reference-ver2_742-worker35 1,12M 186G 2,73T - data/reference-ver2_742-worker36 935K 186G 2,73T - data/reference-ver2_742-worker37 5,27G 186G 2,73T - data/reference-ver2_742-worker38 935K 186G 2,73T - data/reference-ver2_742-worker39 935K 186G 2,73T - data/reference-ver2_742-worker40 935K 186G 2,73T - data/reference-ver2_742-worker41 15,5M 186G 2,73T - data/reference-ver2_742-worker42 934K 186G 2,73T - data/reference-ver2_742-worker43 15,4M 186G 2,73T - data/reference-ver2_742-worker44 429M 186G 2,73T - data/reference-ver2_742-worker45 15,5M 186G 2,73T - data/reference-ver2_742-worker46 935K 186G 2,73T - data/reference-ver2_742-worker47 934K 186G 2,73T - data/reference-ver2_742-worker48 15,5M 186G 2,73T - data/reference-ver2_742-worker49 935K 186G 2,73T - data/reference-ver2_742-worker50 934K 186G 2,73T - data/reference-ver2_742-worker51 935K 186G 2,73T - data/reference-ver2_742-worker52 935K 186G 2,73T - data/reference-ver2_742-worker54 935K 186G 2,73T - data/reference-ver2_742-worker55 934K 186G 2,73T - data/reference-ver2_742-worker57 935K 186G 2,73T - data/reference-ver2_742-worker59 934K 186G 2,73T - data/reference-ver2_742-worker60 15,5M 186G 2,73T - data/reference-ver2_742-worker61 934K 186G 2,73T - data/reference-ver2_742-worker62 934K 186G 2,73T - data/reference-ver2_742-worker63 934K 186G 2,73T - data/reference-ver2_742-worker64 15,5M 186G 2,73T - data/reference-ver2_742-worker65 934K 186G 2,73T - data/reference-ver2_742-worker66 935K 186G 2,73T - data/reference-ver2_742-worker67 934K 186G 2,73T - data/reference-ver2_742-worker68 935K 186G 2,73T - data/reference-ver2_742-worker69 934K 186G 2,73T - data/reference-ver2_742-worker70 935K 186G 2,73T - data/reference-ver2_742-worker71 15,5M 186G 2,73T - data/reference-ver2_742-worker72 935K 186G 2,73T - data/reference-ver2_742-worker73 935K 186G 2,73T - data/reference-ver2_742-worker75 934K 186G 2,73T - data/reference-ver2_742-worker76 935K 186G 2,73T - data/reference-ver2_742-worker77 934K 186G 2,73T - data/reference-ver2_742-worker78 15,7M 186G 2,73T - data/reference-ver2_742-worker79 15,4M 186G 2,73T - data/reference-ver2_742-worker80 935K 186G 2,73T - data/reference-ver7_214-worker07 2,19M 186G 2,73T - data/reference-ver7_214-worker53 2,18M 186G 2,73T - data/userdata 825G 186G 27,2K /data/userdata data/userdata/userdata 27,2K 186G 27,2K /data/userdata/userdata data/userdata/worker01 8,25G 190G 3,77G - data/userdata/worker02 8,25G 190G 3,48G - data/userdata/worker03 8,25G 190G 4,07G - data/userdata/worker04 8,25G 191G 2,99G - data/userdata/worker05 8,25G 190G 3,46G - data/userdata/worker06 8,25G 191G 2,89G - data/userdata/worker07 8,25G 190G 3,65G - data/userdata/worker08 8,25G 190G 3,55G - data/userdata/worker09 8,25G 190G 3,64G - data/userdata/worker10 8,25G 190G 3,85G - data/userdata/worker11 8,25G 191G 3,28G - data/userdata/worker12 8,25G 191G 3,19G - data/userdata/worker13 8,25G 191G 2,93G - data/userdata/worker14 8,25G 191G 2,89G - data/userdata/worker15 8,25G 190G 3,57G - data/userdata/worker153 8,25G 194G 12,8K - data/userdata/worker154 8,25G 194G 12,8K - data/userdata/worker155 8,25G 194G 12,8K - data/userdata/worker156 8,25G 194G 12,8K - data/userdata/worker157 8,25G 194G 12,8K - data/userdata/worker158 8,25G 194G 12,8K - data/userdata/worker159 8,25G 194G 12,8K - data/userdata/worker16 8,25G 190G 4,23G - data/userdata/worker160 8,25G 194G 12,8K - data/userdata/worker161 8,25G 194G 12,8K - data/userdata/worker162 8,25G 194G 12,8K - data/userdata/worker163 8,25G 194G 12,8K - data/userdata/worker164 8,25G 194G 12,8K - data/userdata/worker165 8,25G 194G 12,8K - data/userdata/worker166 8,25G 194G 12,8K - data/userdata/worker167 8,25G 194G 12,8K - data/userdata/worker168 8,25G 194G 12,8K - data/userdata/worker169 8,25G 194G 12,8K - data/userdata/worker17 8,25G 190G 3,63G - data/userdata/worker170 8,25G 194G 12,8K - data/userdata/worker171 8,25G 194G 12,8K - data/userdata/worker172 8,25G 194G 12,8K - data/userdata/worker18 8,25G 191G 3,19G - data/userdata/worker19 8,25G 191G 3,02G - data/userdata/worker20 8,25G 192G 2,35G - data/userdata/worker21 8,25G 188G 5,42G - data/userdata/worker22 8,25G 191G 2,76G - data/userdata/worker23 8,25G 191G 2,61G - data/userdata/worker24 8,25G 191G 3,22G - data/userdata/worker25 8,25G 189G 4,97G - data/userdata/worker26 8,25G 191G 3,23G - data/userdata/worker27 8,25G 189G 4,90G - data/userdata/worker28 8,25G 189G 5,31G - data/userdata/worker29 8,25G 189G 4,67G - data/userdata/worker30 8,25G 190G 3,46G - data/userdata/worker31 8,25G 191G 3,36G - data/userdata/worker32 8,25G 190G 4,11G - data/userdata/worker33 8,25G 190G 4,31G - data/userdata/worker34 8,25G 191G 3,31G - data/userdata/worker35 8,25G 190G 4,23G - data/userdata/worker36 8,25G 191G 3,24G - data/userdata/worker37 8,25G 191G 3,16G - data/userdata/worker38 8,25G 191G 2,89G - data/userdata/worker39 8,25G 189G 4,49G - data/userdata/worker40 8,25G 190G 4,21G - data/userdata/worker41 8,25G 190G 3,42G - data/userdata/worker42 8,25G 191G 3,32G - data/userdata/worker43 8,25G 190G 3,71G - data/userdata/worker44 8,25G 191G 3,33G - data/userdata/worker45 8,25G 189G 5,04G - data/userdata/worker46 8,25G 190G 3,76G - data/userdata/worker47 8,25G 189G 5,13G - data/userdata/worker48 8,25G 190G 3,81G - data/userdata/worker49 8,25G 191G 2,72G - data/userdata/worker50 8,25G 190G 3,78G - data/userdata/worker51 8,25G 191G 3,08G - data/userdata/worker52 8,25G 190G 3,38G - data/userdata/worker53 8,25G 190G 4,10G - data/userdata/worker54 8,25G 190G 3,48G - data/userdata/worker55 8,25G 189G 4,39G - data/userdata/worker56 8,25G 190G 3,58G - data/userdata/worker57 8,25G 190G 3,97G - data/userdata/worker58 8,25G 190G 4,02G - data/userdata/worker59 8,25G 190G 3,57G - data/userdata/worker60 8,25G 190G 4,04G - data/userdata/worker61 8,25G 190G 3,73G - data/userdata/worker62 8,25G 191G 3,21G - data/userdata/worker63 8,25G 191G 3,37G - data/userdata/worker64 8,25G 189G 4,77G - data/userdata/worker65 8,25G 189G 5,34G - data/userdata/worker66 8,25G 190G 3,50G - data/userdata/worker67 8,25G 190G 3,84G - data/userdata/worker68 8,25G 189G 4,73G - data/userdata/worker69 8,25G 191G 3,20G - data/userdata/worker70 8,25G 190G 3,96G - data/userdata/worker71 8,25G 189G 5,11G - data/userdata/worker72 8,25G 191G 2,92G - data/userdata/worker73 8,25G 189G 4,53G - data/userdata/worker74 8,25G 189G 4,39G - data/userdata/worker75 8,25G 190G 4,26G - data/userdata/worker76 8,25G 189G 4,67G - data/userdata/worker77 8,25G 189G 5,30G - data/userdata/worker78 8,25G 190G 3,98G - data/userdata/worker79 8,25G 190G 4,10G - data/userdata/worker80 8,25G 190G 3,48G - This are getting really complicated now. What I don't understand is: - why the amount of free space changes from dataset to dataset ? I mean they all share the same free space pool, all have the same refreservation=none, but the AVAIL differs. When it comes to workerX datasets, it differs slightly, but when it comes to the large zvols, like esx/shared or reference, it differs a lot ! - why the esx/shared and reference datasets are shown like they can be enlarged ? I mean, I really don't have THAT much of free space. Here are their properties: [emz@san01:~]> zfs get all data/esx/shared NAME PROPERTY VALUE SOURCE data/esx/shared type volume - data/esx/shared creation вт февр. 21 10:19 2017 - data/esx/shared used 5,02T - data/esx/shared available 2,59T - data/esx/shared referenced 2,61T - data/esx/shared compressratio 1.81x - data/esx/shared reservation none default data/esx/shared volsize 5T local data/esx/shared volblocksize 64K - data/esx/shared checksum on default data/esx/shared compression lzjb inherited from data data/esx/shared readonly off default data/esx/shared copies 1 default data/esx/shared refreservation 5,02T local data/esx/shared primarycache all default data/esx/shared secondarycache all default data/esx/shared usedbysnapshots 0 - data/esx/shared usedbydataset 2,61T - data/esx/shared usedbychildren 0 - data/esx/shared usedbyrefreservation 2,41T - data/esx/shared logbias latency default data/esx/shared dedup off default data/esx/shared mlslabel - data/esx/shared sync standard default data/esx/shared refcompressratio 1.81x - data/esx/shared written 2,61T - data/esx/shared logicalused 4,71T - data/esx/shared logicalreferenced 4,71T - data/esx/shared volmode default default data/esx/shared snapshot_limit none default data/esx/shared snapshot_count none default data/esx/shared redundant_metadata all default [emz@san01:~]> zfs get all data/reference NAME PROPERTY VALUE SOURCE data/reference type volume - data/reference creation вт февр. 21 11:12 2017 - data/reference used 6,74T - data/reference available 4,17T - data/reference referenced 2,73T - data/reference compressratio 1.08x - data/reference reservation none default data/reference volsize 3,97T local data/reference volblocksize 64K - data/reference checksum on default data/reference compression lzjb local data/reference readonly off default data/reference copies 1 default data/reference refreservation 3,98T local data/reference primarycache all default data/reference secondarycache all default data/reference usedbysnapshots 21,6G - data/reference usedbydataset 2,73T - data/reference usedbychildren 0 - data/reference usedbyrefreservation 3,98T - data/reference logbias latency default data/reference dedup off default data/reference mlslabel - data/reference sync standard default data/reference refcompressratio 1.08x - data/reference written 1,10M - data/reference logicalused 2,98T - data/reference logicalreferenced 2,95T - data/reference volmode default default data/reference snapshot_limit none default data/reference snapshot_count none default data/reference redundant_metadata all default Could please someone explain why they show as having like half of the total pool space as AVAIL ? I thing this is directly related to the fact that zpool list shows only 44% of the total pool space is used. And I use this value to monitor the pool space usage, looks like I'm totally failing with this. I also don't understand whe the zvol of the size 3.97T really uses 6.74T of the space. I found an article, explaing that the volblocksize and the sector size has to do something with this, and this happens when the device block size is 4k, and volblocksize is default, thus 8k. Mine disks sector size is 512 native, so this is really not the case. I'm also having equal number of disks in vdevs, and they are 5: [root@san01:~]# zpool status data pool: data state: ONLINE scan: scrub repaired 111K in 40h42m with 0 errors on Wed Mar 1 03:34:56 2017 config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 diskid/DISK-96JS100XTB4V ONLINE 0 0 0 diskid/DISK-96JS101TTB4V ONLINE 0 0 0 diskid/DISK-96JS100MTB4V ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 diskid/DISK-96JS1016TB4V ONLINE 0 0 0 diskid/DISK-96JS1002TB4V ONLINE 0 0 0 diskid/DISK-96LS1066TB4V ONLINE 0 0 0 diskid/DISK-96JS101JTB4V ONLINE 0 0 0 diskid/DISK-96LS106TTB4V ONLINE 0 0 0 errors: No known data errors So I guess poor vdev alignment is also not the case. I used to resize the zvol a couple of times, and I suspect this is the main reason, because I've read in another article that this is probably the case when "poor alignment" happens. I will really appreciate if someone will explain this. Thanks. From owner-freebsd-fs@freebsd.org Wed Apr 12 18:12:46 2017 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 2D5ECD3B92E for ; Wed, 12 Apr 2017 18:12:46 +0000 (UTC) (envelope-from chris@stankevitz.com) Received: from mango.stankevitz.com (mango.stankevitz.com [208.79.93.194]) by mx1.freebsd.org (Postfix) with ESMTP id 20B408BE for ; Wed, 12 Apr 2017 18:12:45 +0000 (UTC) (envelope-from chris@stankevitz.com) Received: from stink.local (209-203-101-124.static.twtelecom.net [209.203.101.124]) by mango.stankevitz.com (Postfix) with ESMTPSA id 7FADC3CC6F for ; Wed, 12 Apr 2017 11:07:23 -0700 (PDT) To: freebsd-fs@freebsd.org From: Chris Stankevitz Subject: ZFS ACL Inheritance: umask and canonical ACEs Message-ID: <5aaf7f68-d099-c72a-c396-82b6597e7e01@stankevitz.com> Date: Wed, 12 Apr 2017 11:07:20 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.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: Wed, 12 Apr 2017 18:12:46 -0000 Hi, Questions (detail appears later): 1. Why wasn't my "inherited" ACE faithfully inherited? Namely, the so-called inherited ACE does not have "rwxp--aARWcCos". Clearly the way inheritance works is a function of the shell's umask (or in my real scenario -- Samba's umask). I would like for inherited ACEs to not be a function of umask. 2. How do I tell ZFS/ACL that I do not want owner@, group@, or everything@ ACEs created unless explicitly requested by setfacl? I do not want "extra" ACEs to appear on files I create within a particular directory -- even these "canonical" ACEs. 3. Bonus question: why does 'man setfacl' reference six canonical ACEs but there are only 3 (owner@, group@, everyone@)? Thank you, Chris PS: I am using aclmode=passthrough and aclinherit=passthrough ===== I have a directory with this ACL: # file . # owner: cstankevitz # group: cstankevitz group:cstankevitz:rwxp--aARWcCos:fd-----:allow Note that I have removed owner@, group@, and everyone@ ACEs. Also notice that the single ACE allows rwxp--aARWcCos access to cstankevitz and that it is supposed to be inherited. Inside this directory, I do this: umask 000 touch bar.txt getfacl bar.txt # file: bar.txt # owner: cstankevitz # group: cstankevitz group:cstankevitz:rw-p--a-R-c--s:------I:allow owner@:rw-p--aARWcCos:-------:allow group@:rw-p--a-R-c--s:-------:allow everyone@:rw-p--a-R-c--s:-------:allow umask 777 touch foo.txt getfacl foo.txt # file: foo.txt # owner: cstankevitz # group: cstankevitz group:cstankevitz:------a-R-c--s:------I:allow owner@:------aARWcCos:-------:allow group@:------a-R-c--s:-------:allow everyone@:------a-R-c--s:-------:allow From owner-freebsd-fs@freebsd.org Wed Apr 12 18:25:44 2017 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 0C337D3BD81; Wed, 12 Apr 2017 18:25:44 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB20229; Wed, 12 Apr 2017 18:25:43 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cyMxS-0004DC-G0; Wed, 12 Apr 2017 20:25:35 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org, "freebsd-fs@freebsd.org" Subject: Re: newfs_nandfs compile error 11-STABLE References: Date: Wed, 12 Apr 2017 20:25:33 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: d40e2d9e04d28df092fb73f3743f8c9c 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: Wed, 12 Apr 2017 18:25:44 -0000 On Wed, 05 Apr 2017 12:46:01 +0200, Ronald Klop wrote: > Hi, > > I'm building 11-STABLE for SHEEVAPLUG on a 12-CURRENT/amd64. > I get this compile error. > How can I resolve this without a clean build? I would like to prevent > recompiling llvm for 12 hours. > > --- newfs_nandfs.o --- > cc -O -pipe -g -MD -MF.depend.newfs_nandfs.o -MTnewfs_nandfs.o > -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline > -Wnested-externs -Wredundant-decls -Wold-style-definition > -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable > -Qunused-arguments -c /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c -o > newfs_nandfs.o > /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking > address of packed member 'f_uuid' of class or structure 'nandfs_fsdata' > may result in an unaligned pointer value > [-Werror,-Waddress-of-packed-member] > uuidgen(&fsdata.f_uuid, 1); > ^~~~~~~~~~~~~ > 1 error generated. > *** [newfs_nandfs.o] Error code 1 > > make[4]: stopped in /usr/src-arm/sbin/newfs_nandfs > 1 error > > make[4]: stopped in /usr/src-arm/sbin/newfs_nandfs > *** [all_subdir_sbin/newfs_nandfs] Error code 2 > > > Do I have to clean and rebuild some specific library? > Or something else? > > Regards, > Ronald. I cleaned, did rm -r /usr/obj-arm/*, waited for half a day compiling llvm and got the same error. This is while compiling 11-STABLE/arm on 12-CURRENT/amd64. ===> sbin/newfs_nandfs (all) echo newfs_nandfs.full: /usr/obj-arm/arm.arm/usr/src-arm/tmp/usr/lib/libc.a /usr /obj-arm/arm.arm/usr/src-arm/tmp/usr/lib/libgeom.a >> .depend cc -O -pipe -g -MD -MF.depend.newfs_nandfs.o -MTnewfs_nandfs.o -std=gnu99 -W system-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-p rototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite -strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wi nline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sig n -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-pl us-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src-arm/sbin/newf s_nandfs/newfs_nandfs.c -o newfs_nandfs.o /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking address of p acked member 'f_uuid' of class or structure 'nandfs_fsdata' may result in an una ligned pointer value [-Werror,-Waddress-of-packed-member] uuidgen(&fsdata.f_uuid, 1); ^~~~~~~~~~~~~ 1 error generated. *** Error code 1 Any ideas? Ronald. From owner-freebsd-fs@freebsd.org Wed Apr 12 19:20:39 2017 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 18472D3B3C1; Wed, 12 Apr 2017 19:20:39 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002: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 CC4ECCC2; Wed, 12 Apr 2017 19:20:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x229.google.com with SMTP id j9so16399950ywj.3; Wed, 12 Apr 2017 12:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=k/kotrJScR2Ps5zMciC8N6nuMXXQnEkykIYvsdVifk0=; b=EilNL9aXFQ1sGHpxzyQjaNlyL0CYn6RKRMowUz7yyDQdsrkimjHOpfWb8Dgt0gwLxT PbNSfyh5EyQt06OLLl8Jg67e8CoifoBQS8D9axd4aN2rWvxrhfZB6Q6cPEimeUSLBcr1 4vsK17vPmmxbeR9k7vPwXqCJ3CAdiE4y+WS5fJU/5zyNTiJ0wOmYaYaEtcDnxjm2eXZH N5cUTr1NyCPTIewiSeQgaVj+b0k8UIxydNl0hAgGLP9z15cFr87PvVav7rje8FAaNP9B V9OJyQ4mgUHsZiNyQWuLgvKWx5IMUVqPCERoT/0VIcica2ihJpFuETi2FsXgkRauX0ih /mmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=k/kotrJScR2Ps5zMciC8N6nuMXXQnEkykIYvsdVifk0=; b=ah088oGgmexz6Q9lnskUplFlJwWrcrH0gMpo+negFNOuFuiqYS0w5iifTf1+DIoPm2 dllnJ/5YiFvSofXHX1lWj1hHQuB/65faVzE3Mtz3s5apACjpAMblvlZ5M1vNDIdM8WVb AfSJmkgERN86hWYPisima1nE3LNH16BhdU4hujcuKIVQtf8MofYL1GgAd7e0FZ+bTSiH C/OJ+PXxmZs9wiIW98nc9weED3jesssljKW2jng70bYcDS4BzCzMHgs9MajEPUWfda4W Zm2ABR6oumVWK6/0deaINhUZl4FXsvZN9KLseMROy/PZDtREk6396LZImJuv72PCMCl5 qEiw== X-Gm-Message-State: AN3rC/719+HO1sA+/HLH3bddDCtv2zfZ76DypOrJcVqnfI3EcNlkzRWvGdS1/rwrsPX7uu3cTgA3OcAnUBz1ig== X-Received: by 10.129.173.69 with SMTP id l5mr8155955ywk.351.1492024837733; Wed, 12 Apr 2017 12:20:37 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.20.214 with HTTP; Wed, 12 Apr 2017 12:20:37 -0700 (PDT) In-Reply-To: <71ef8400-94ec-1f59-3b2b-bb576ad65b89@norma.perm.ru> References: <71ef8400-94ec-1f59-3b2b-bb576ad65b89@norma.perm.ru> From: Alan Somers Date: Wed, 12 Apr 2017 13:20:37 -0600 X-Google-Sender-Auth: jbmXM0ZpdrCEXnabGKrRoNu6EjE Message-ID: Subject: Re: zpool list show nonsense on raidz pools, at least it looks like it for me To: "Eugene M. Zheganin" Cc: FreeBSD , FreeBSD FS Content-Type: text/plain; charset=UTF-8 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: Wed, 12 Apr 2017 19:20:39 -0000 On Wed, Apr 12, 2017 at 12:01 PM, Eugene M. Zheganin wrote: > Hi, > > > It's not my first letter where I fail to understand the space usage from zfs > utilities, and in previous ones I was kind of convinced that I just read it > wrong, but not this time I guess. See for yourself: > > > [emz@san01:~]> zpool list data > NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT > data 17,4T 7,72T 9,66T - 46% 44% 1.00x ONLINE - > > > Here' as I understand it, zpool says that less than a half of the pool is > used. As far as I know this is very complicated when it comes to the radiz > pools. Let's see: > > > [emz@san01:~]> zfs list -t all data > NAME USED AVAIL REFER MOUNTPOINT > data 13,3T 186G 27,2K /data > > > So, if we won't investigate further, it looks like that only 186G is free. > Spoiling - this is the real free space amount, because I've just managed to > free 160 gigs of data, and I really know I was short on space when sending > 30 Gb dataset, because zfs was saying "Not enough free space". So, let's > investigate further: > > > [emz@san01:~]> zfs list -t all | more > NAME USED AVAIL REFER MOUNTPOINT > data 13,3T 186G 27,2K /data > data/esx 5,23T 186G 27,2K /data/esx ... > data/esx/boot-esx26 8,25G 194G 12,8K - > data/esx/shared 5,02T 2,59T 2,61T - > data/reference 6,74T 4,17T 2,73T - > data/reference@ver7_214 127M - 2,73T - > data/reference@ver2_739 12,8M - 2,73T - > data/reference@ver2_740 5,80M - 2,73T - > data/reference@ver2_741 4,55M - 2,73T - > data/reference@ver2_742 993K - 2,73T - > data/reference-ver2_739-worker100 1,64G 186G 2,73T - ... > > > This are getting really complicated now. > > What I don't understand is: > > - why the amount of free space changes from dataset to dataset ? I mean they > all share the same free space pool, all have the same refreservation=none, > but the AVAIL differs. When it comes to workerX datasets, it differs > slightly, but when it comes to the large zvols, like esx/shared or > reference, it differs a lot ! > > - why the esx/shared and reference datasets are shown like they can be > enlarged ? I mean, I really don't have THAT much of free space. > > > Here are their properties: > > > [emz@san01:~]> zfs get all data/esx/shared > NAME PROPERTY VALUE SOURCE ... > data/esx/shared refreservation 5,02T local ... > [emz@san01:~]> zfs get all data/reference > NAME PROPERTY VALUE SOURCE ... > data/reference refreservation 3,98T local ... > > > Could please someone explain why they show as having like half of the total > pool space as AVAIL ? I thing this is directly related to the fact that > zpool list shows only 44% of the total pool space is used. And I use this > value to monitor the pool space usage, looks like I'm totally failing with > this. > Some of your datasets have refreservations. That's why. > > I also don't understand whe the zvol of the size 3.97T really uses 6.74T of > the space. I found an article, explaing that the volblocksize and the sector > size has to do something with this, and this happens when the device block > size is 4k, and volblocksize is default, thus 8k. Mine disks sector size is > 512 native, so this is really not the case. I'm also having equal number of > disks in vdevs, and they are 5: > The AVAIL reported by zpool list doesn't account for RAIDZ overhead (or maybe it assumes optimum alignment; I can't remember). But the USED reported by "zfs list" does account for RAIDZ overhead. -alan From owner-freebsd-fs@freebsd.org Wed Apr 12 19:22:33 2017 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 16463D3B658; Wed, 12 Apr 2017 19:22:33 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE54D17D; Wed, 12 Apr 2017 19:22:32 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::11dd:a3c9:6e43:3dce] (unknown [IPv6:2001:470:7a58:0:11dd:a3c9:6e43:3dce]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id ADDFE240B7; Wed, 12 Apr 2017 21:22:22 +0200 (CEST) From: Dimitry Andric Message-Id: <1F217A73-A90C-4F82-8726-88B57FC221C9@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_58F000DB-E6A1-4CA2-9D1F-9A3CDC83A58A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: newfs_nandfs compile error 11-STABLE Date: Wed, 12 Apr 2017 21:22:13 +0200 In-Reply-To: Cc: freebsd-arm@freebsd.org, "freebsd-fs@freebsd.org" To: Ronald Klop References: X-Mailer: Apple Mail (2.3273) 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: Wed, 12 Apr 2017 19:22:33 -0000 --Apple-Mail=_58F000DB-E6A1-4CA2-9D1F-9A3CDC83A58A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Apr 2017, at 20:25, Ronald Klop wrote: >=20 > On Wed, 05 Apr 2017 12:46:01 +0200, Ronald Klop = wrote: ... > /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking = address of p > acked member 'f_uuid' of class or structure 'nandfs_fsdata' may result = in an una > ligned pointer value [-Werror,-Waddress-of-packed-member] > uuidgen(&fsdata.f_uuid, 1); > ^~~~~~~~~~~~~ > 1 error generated. > *** Error code 1 >=20 >=20 > Any ideas? Either use NO_WERROR, or ensure you have at least r314671, where this warning was fixed. -Dimitry --Apple-Mail=_58F000DB-E6A1-4CA2-9D1F-9A3CDC83A58A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljufm4ACgkQsF6jCi4glqPCOACdE1D8F0LcuTmFXZ/v2zbejOvu uUkAnj1dyvNCY9v8qBHq6xqTLdWfKdTI =Fk3a -----END PGP SIGNATURE----- --Apple-Mail=_58F000DB-E6A1-4CA2-9D1F-9A3CDC83A58A-- From owner-freebsd-fs@freebsd.org Wed Apr 12 19:30:08 2017 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 E967BD3B9D5 for ; Wed, 12 Apr 2017 19:30:08 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 BB3C88C1 for ; Wed, 12 Apr 2017 19:30:08 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: by mail-pg0-x231.google.com with SMTP id x125so19354611pgb.0 for ; Wed, 12 Apr 2017 12:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cSQxnX4EZwNFkS1e8HKdjINP7UC/LL8ayS9DwjcSWEc=; b=iFVldBO588xgYJ3hrALoRhrHE8Cl76HaeFevM0rQUFvJucZcfLK0VlXj7cCJUb0XO2 jJ+cKUgA1KAZuAH51dHSH6k6u7UhclMkh5C3Hey6Wd5Db2+Xla7v4c862TZbG6wv5q1G YE8kdfxQuQGulr8uNRSk5+HrL9s7ysgrXlg+NLYkKGVL+sJsv/iolTPEEURgvyDasvmF EJm2orUIOXC454PrUuXkFMpWA25svqETG/W0+CmxVQwKnzoP6YQ5TjgszOk5uV28O2wI hXS+DNsK6dtl5RKbqlUiugdsTmEEveT3GCqGgOiXuULxuCMwkrcbo4ksHSNTUPgSYua2 Fvfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cSQxnX4EZwNFkS1e8HKdjINP7UC/LL8ayS9DwjcSWEc=; b=WLlt03pIBeonIIqlfkfv274d/zg8skw77+sIRRNAB+yulTq+IAwnLzYwogSVCvEN2y 99tlcco1lGsZSA6wPdLWUfcWuk9/13AzLNyJkZQwEmcWbG9nQUJj6UuPi1n7A7WiSIfm 7spnoyKXSZntBPuDRqw8K9Mlc3oJ6gLGLLgOgKylX8qXbOkergXGJDaA5LsQ+pYB+bSK h+ext870cGv7Cba/FvODnUCi9Nn71oxcXTGE+mjZU/EUdxRfCjjrViP7Lvd4qbBfon5M wwNEQof+5jPNP+iX7QSZ5PReTTmyaBW+oCQHwziLPnl6VfrFbRAqfXlgpPGlGDwUZSdt Xmog== X-Gm-Message-State: AFeK/H0a4npYdfTqtvZcjvRCmq5DNyplWIEvr3npEQ5EH6ndmgUk4uYhgKkyHeNQ51KfhwZ3MHuplfSPR9LK2g== X-Received: by 10.99.164.26 with SMTP id c26mr70759874pgf.89.1492025408313; Wed, 12 Apr 2017 12:30:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.8 with HTTP; Wed, 12 Apr 2017 12:30:07 -0700 (PDT) In-Reply-To: <71ef8400-94ec-1f59-3b2b-bb576ad65b89@norma.perm.ru> References: <71ef8400-94ec-1f59-3b2b-bb576ad65b89@norma.perm.ru> From: "Eric A. Borisch" Date: Wed, 12 Apr 2017 14:30:07 -0500 Message-ID: Subject: Re: zpool list show nonsense on raidz pools, at least it looks like it for me To: "Eugene M. Zheganin" Cc: FreeBSD FS 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: Wed, 12 Apr 2017 19:30:09 -0000 OK. There's a lot going on here. A few notes: 1) Look at the output of 'zfs list -ro space data' ... this does a nice job of showing what is actually using space. 2) Volumes with refreservation *and* snapshots take up *at least* refreservation size + usedbysnapshots size, and frequently much more. This is because you have a contract to allow the user to re-write (change) the full refreservation size without running out of space, while still retaining any data currently pointed to by a snapshot (this *is not* the same as usedbysnapshots). If you want to 'thin provision', set refreservation=none, but be aware of what you are doing and potential for problems if you start actually filling up all the volumes. You can see this all in your listing: data/reference used 6,74T - data/reference available 4,17T - data/reference referenced 2,73T - data/reference volsize 3,97T local data/reference refreservation 3,98T local data/reference usedbysnapshots 21,6G - data/reference usedbydataset 2,73T - data/reference usedbychildren 0 - data/reference usedbyrefreservation 3,98T - Note especially the usedbydataset and usedbyrefreservation line. I'm guessing you have a recent snapshot, such that ZFS guarantees its existence (and the 2.73TB it references) AS WELL AS being able to rewrite the whole 4TB volume without running out of space. All of these refreservations are what is consuming your space available from the zfs (not zpool) perspective. The 'available' property here is your volsize + the available size from 'zfs list data'. (How much you could grow this volume to; its "available" size.) 3) The zpool listing (and space available) is 'ignorant' of reservations, this is a statement of how much data is currently active (written to and still referenced by active datasets/volumes/snapshots) on the drives, and how much space on the drives is free to write over. 4) You can get into other overheads with different raid-z levels and pool widths, but that's not an issue here. Hope that helps, - Eric From owner-freebsd-fs@freebsd.org Wed Apr 12 19:33:00 2017 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 DC0F1D3BC39; Wed, 12 Apr 2017 19:33:00 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A64EADA7; Wed, 12 Apr 2017 19:32:59 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cyO0e-0001k4-UN; Wed, 12 Apr 2017 21:32:57 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Dimitry Andric" , "Conrad E. Meyer" Cc: freebsd-arm@freebsd.org, "freebsd-fs@freebsd.org" Subject: Re: newfs_nandfs compile error 11-STABLE References: <1F217A73-A90C-4F82-8726-88B57FC221C9@FreeBSD.org> Date: Wed, 12 Apr 2017 21:32:56 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <1F217A73-A90C-4F82-8726-88B57FC221C9@FreeBSD.org> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 0ccaee305be983877c9e38c09cbf8ec4 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: Wed, 12 Apr 2017 19:33:01 -0000 On Wed, 12 Apr 2017 21:22:13 +0200, Dimitry Andric wrote: > On 12 Apr 2017, at 20:25, Ronald Klop wrote: >> >> On Wed, 05 Apr 2017 12:46:01 +0200, Ronald Klop >> wrote: > ... >> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking >> address of p >> acked member 'f_uuid' of class or structure 'nandfs_fsdata' may result >> in an una >> ligned pointer value [-Werror,-Waddress-of-packed-member] >> uuidgen(&fsdata.f_uuid, 1); >> ^~~~~~~~~~~~~ >> 1 error generated. >> *** Error code 1 >> >> >> Any ideas? > > Either use NO_WERROR, or ensure you have at least r314671, where this > warning was fixed. > > -Dimitry > I cc the original committer cem@freebsd. Is it possible to merge r314671 to 11-CURRENT? Regards, Ronald. From owner-freebsd-fs@freebsd.org Wed Apr 12 19:39:46 2017 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 F1EEFD3BE67 for ; Wed, 12 Apr 2017 19:39:46 +0000 (UTC) (envelope-from chris@stankevitz.com) Received: from mango.stankevitz.com (mango.stankevitz.com [208.79.93.194]) by mx1.freebsd.org (Postfix) with ESMTP id E301815F for ; Wed, 12 Apr 2017 19:39:46 +0000 (UTC) (envelope-from chris@stankevitz.com) Received: from stink.local (209-203-101-124.static.twtelecom.net [209.203.101.124]) by mango.stankevitz.com (Postfix) with ESMTPSA id 1F40F3CCAD; Wed, 12 Apr 2017 12:39:46 -0700 (PDT) Subject: Re: ZFS ACL Inheritance: umask and canonical ACEs To: Chris Stankevitz , freebsd-fs@freebsd.org References: <5aaf7f68-d099-c72a-c396-82b6597e7e01@stankevitz.com> From: Chris Stankevitz Message-ID: <43807c41-d553-04cb-8b41-d7a809ba6403@stankevitz.com> Date: Wed, 12 Apr 2017 12:39:44 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5aaf7f68-d099-c72a-c396-82b6597e7e01@stankevitz.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:39:47 -0000 On 4/12/17 11:07 AM, Chris Stankevitz wrote: 2. How do I tell ZFS/ACL that I do not want owner@, group@, or > everything@ ACEs created unless explicitly requested by setfacl? I do > not want "extra" ACEs to appear on files I create within a particular > directory -- even these "canonical" ACEs. https://github.com/freebsd/freebsd/blob/master/sys/kern/subr_acl_nfs4.c From sys/kern/subr_acl_nfsv4.c acl_nfs4_compute_inherited_acl_psarc (which I'm guessing is called when a file is created): _acl_append(aclp, ACL_USER_OBJ, user_allow ... _acl_append(aclp, ACL_GROUP_OBJ, group_allow ... _acl_append(aclp, ACL_EVERYONE, everyone_allow ... So it looks like I must have an @owner, @group, and @everyone at creation. On Windows if you have a directory containing just one to-be-inherited ACE -- when you create a file within that directory, that new file also contains just one ACE. Apparently on FreeBSD/ZFS you get some more "special" ACEs that appear whether you want them or not. My Windows users (via Samba) are not used to these "bonus ACEs" appearing when they create files. Chris From owner-freebsd-fs@freebsd.org Wed Apr 12 20:53:59 2017 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 A54EBD3B4D5; Wed, 12 Apr 2017 20:53:59 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) (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 444F03D8; Wed, 12 Apr 2017 20:53:58 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-wm0-f45.google.com with SMTP id t189so33220169wmt.1; Wed, 12 Apr 2017 13:53:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=PO3RR7I9euUBPoqLLDwuE5W/5au9/pkT7JXIN8jKwK8=; b=MbfavXRY8AtC2OC8UWd72KTECnalXOCpDcuv9WwDowqUP9zwvbsiSbc5O8zwP2jufO +3MY8M9S7i/y5Nyp0OkuwO055SWvhe5w4s5cQCngOdhBTuRTaMu0J0ErjR0+ve+A9LJE BlqebHWmRZzKUdxfvSTzwCwMb0gVzpHuUC03fh5SyQSduiEaIV1guMHmIsVwmDN1Bycq tN6sM9dr2iFp3iKvkA1E5cgKVy3glF0FolKIcO2ZMmc3kC/IdFGiasPxtb6tXWvRlm7j L2jdpvr6lKkGMdZJUceVWHa6d/UFeLgfvdiGYaAjrJ7b+2fQoo1XLC0WYHtVkFeKxDlo IfXQ== X-Gm-Message-State: AN3rC/4LDRy5TWK3kRdYBUgTM+eSmCt50yc8LgrT009KUeprvHnIUR4L L2Ver8sDuOkjvJmSWlc= X-Received: by 10.28.14.138 with SMTP id 132mr53308wmo.141.1492028901228; Wed, 12 Apr 2017 13:28:21 -0700 (PDT) Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com. [209.85.128.174]) by smtp.gmail.com with ESMTPSA id 33sm26688822wrd.40.2017.04.12.13.28.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 13:28:20 -0700 (PDT) Received: by mail-wr0-f174.google.com with SMTP id c55so24333649wrc.3; Wed, 12 Apr 2017 13:28:20 -0700 (PDT) X-Received: by 10.223.131.67 with SMTP id 61mr4729383wrd.57.1492028900741; Wed, 12 Apr 2017 13:28:20 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.80.169.4 with HTTP; Wed, 12 Apr 2017 13:28:20 -0700 (PDT) In-Reply-To: References: <1F217A73-A90C-4F82-8726-88B57FC221C9@FreeBSD.org> From: Conrad Meyer Date: Wed, 12 Apr 2017 13:28:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: newfs_nandfs compile error 11-STABLE To: Ronald Klop Cc: Dimitry Andric , freebsd-arm , "freebsd-fs@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Wed, 12 Apr 2017 20:53:59 -0000 I don't do MFCs. Someone else is free to do so. On Wed, Apr 12, 2017 at 12:32 PM, Ronald Klop wrote: > On Wed, 12 Apr 2017 21:22:13 +0200, Dimitry Andric wrote: > >> On 12 Apr 2017, at 20:25, Ronald Klop wrote: >>> >>> >>> On Wed, 05 Apr 2017 12:46:01 +0200, Ronald Klop >>> wrote: >> >> ... >>> >>> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking >>> address of p >>> acked member 'f_uuid' of class or structure 'nandfs_fsdata' may result in >>> an una >>> ligned pointer value [-Werror,-Waddress-of-packed-member] >>> uuidgen(&fsdata.f_uuid, 1); >>> ^~~~~~~~~~~~~ >>> 1 error generated. >>> *** Error code 1 >>> >>> >>> Any ideas? >> >> >> Either use NO_WERROR, or ensure you have at least r314671, where this >> warning was fixed. >> >> -Dimitry >> > > > I cc the original committer cem@freebsd. Is it possible to merge r314671 to > 11-CURRENT? > > Regards, > Ronald. From owner-freebsd-fs@freebsd.org Thu Apr 13 17:13:19 2017 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 2222AD3B4F8; Thu, 13 Apr 2017 17:13:19 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFD2E86E; Thu, 13 Apr 2017 17:13:18 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::21d5:18c1:7aec:de4a] (unknown [IPv6:2001:470:7a58:0:21d5:18c1:7aec:de4a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 83F9C2414C; Thu, 13 Apr 2017 19:13:16 +0200 (CEST) From: Dimitry Andric Message-Id: <54B86FBF-1108-40D4-B699-AC6E8366DBE6@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_26A1F3FA-7614-4859-A5F8-674B7B7DD651"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: newfs_nandfs compile error 11-STABLE Date: Thu, 13 Apr 2017 19:13:07 +0200 In-Reply-To: Cc: "freebsd-fs@freebsd.org" , freebsd-arm To: Ronald Klop References: <1F217A73-A90C-4F82-8726-88B57FC221C9@FreeBSD.org> X-Mailer: Apple Mail (2.3273) 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, 13 Apr 2017 17:13:19 -0000 --Apple-Mail=_26A1F3FA-7614-4859-A5F8-674B7B7DD651 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Apr 2017, at 22:28, Conrad Meyer wrote: >=20 > I don't do MFCs. Someone else is free to do so. > On Wed, Apr 12, 2017 at 12:32 PM, Ronald Klop = wrote: >> On Wed, 12 Apr 2017 21:22:13 +0200, Dimitry Andric = wrote: ... >>>> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking >>>> address of p >>>> acked member 'f_uuid' of class or structure 'nandfs_fsdata' may = result in >>>> an una >>>> ligned pointer value [-Werror,-Waddress-of-packed-member] >>>> uuidgen(&fsdata.f_uuid, 1); >>>> ^~~~~~~~~~~~~ ... >> I cc the original committer cem@freebsd. Is it possible to merge = r314671 to >> 11-CURRENT? Merged to stable/11 and stable/10 in r316772. -Dimitry --Apple-Mail=_26A1F3FA-7614-4859-A5F8-674B7B7DD651 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljvsasACgkQsF6jCi4glqPUiQCg2qlurWWln3E4JtqQsmbI9fuV A5MAoPRZAPWK0sUIZCIBmnVY+XAur7qe =tH8J -----END PGP SIGNATURE----- --Apple-Mail=_26A1F3FA-7614-4859-A5F8-674B7B7DD651-- From owner-freebsd-fs@freebsd.org Thu Apr 13 19:03:19 2017 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 EE516D3C044 for ; Thu, 13 Apr 2017 19:03:19 +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 DE421DD1 for ; Thu, 13 Apr 2017 19:03:19 +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 v3DJ3JGB017186 for ; Thu, 13 Apr 2017 19:03:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 218636] [fuse] [bug] kernel_cache is enabled by default Date: Thu, 13 Apr 2017 19:03:19 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some 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 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: Thu, 13 Apr 2017 19:03:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218636 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Apr 13 19:04:41 2017 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 B20DBD3C263 for ; Thu, 13 Apr 2017 19:04:41 +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 A1CE71000 for ; Thu, 13 Apr 2017 19:04:41 +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 v3DJ4fYN019283 for ; Thu, 13 Apr 2017 19:04:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 218626] [PATCH] cuse: new error code CUSE_ERR_NO_DEVICE (ENODEV) Date: Thu, 13 Apr 2017 19:04:41 +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: CURRENT 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 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: Thu, 13 Apr 2017 19:04:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218626 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Apr 14 22:44:56 2017 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 41F25D3D926 for ; Fri, 14 Apr 2017 22:44:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670070.outbound.protection.outlook.com [40.107.67.70]) (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 E5D7DA16 for ; Fri, 14 Apr 2017 22:44:55 +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_128_CBC_SHA256_P256) id 15.1.1019.17; Fri, 14 Apr 2017 22:44:53 +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.1019.028; Fri, 14 Apr 2017 22:44:53 +0000 From: Rick Macklem To: "freebsd-fs@freebsd.org" CC: "jim@ks.uiuc.edu" Subject: NFSv4 Linux client atime for exclusive create Thread-Topic: NFSv4 Linux client atime for exclusive create Thread-Index: AQHStW9Xwd3iU1MkQkKHy7u7vlbe/w== Date: Fri, 14 Apr 2017 22:44:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ks.uiuc.edu; dkim=none (message not signed) header.d=none;ks.uiuc.edu; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0189; 7:RkFzHZdqXP3KMZ3qRQidhNjDkaVwlsbaVZQcfHd0v+bBMp8FqSxipKi5xG6R51HF+tTW3likvqIjYhy/83/jmkKkaWAkbGDkTRIGlxZWrieKroEoviHArMMddeNcAHJfO9XLfmuL+/vDVGKqROTfK2htISljlYtDgj9a0fgRmmMh8f8O2YA/5x8vvbV08K63URFAhofnjVfrrLS0rSVYtmIQhvaSs3ahDNGvemTgJ8s09BXn/Z8js1Faiba2sDWq1Wivd+WxZIEEmA7fwYELtOyzBPhJe96m1nnVMhkEJ0ZxIIQkJZB4WX1rzuYYJFaAMn4OIjTmWFc3pRTr7HzOsg== x-ms-office365-filtering-correlation-id: e72e16dc-e8c2-4e5d-c1d9-08d48387de1d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:YTXPR01MB0189; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(20558992708506); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123555025)(20161123562025)(6072148); SRVR:YTXPR01MB0189; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0189; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39400400002)(39840400002)(33656002)(25786009)(4326008)(110136004)(74316002)(305945005)(2900100001)(54356999)(50986999)(2351001)(2501003)(38730400002)(3280700002)(6916009)(8676002)(86362001)(5640700003)(81166006)(7696004)(77096006)(2906002)(55016002)(8936002)(6436002)(53936002)(3660700001)(9686003)(6506006)(74482002)(189998001)(102836003)(122556002)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0189; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 14 Apr 2017 22:44:53.4827 (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: Fri, 14 Apr 2017 22:44:56 -0000 PR#218218 reports a problem where a file created by an NFSv4 mount (using a= recent Linux kernel) results in a bogus atime for the newly created file. With the help of a packet trace from the problem reported I now know what i= s happening, but it turns out to be interesting and I am not sure I have a go= od way to fix it. Here's the story... - The Linux client does an Exclusive create. - As was the norm for NFSv3, the FreeBSD server stores the create_verifier = for this exclusive create in the atime field of the newly created file, so it can = be checked for a retry of the exclusive create. --> For NFSv3, it was required that a client follow an exclusive create w= ith a Setattr of atime to fix the atime. It turns out that, for NFSv4, the client is not required to do the Setattr = of atime. (The FreeBSD client does do this and I think older Linux NFSv4 clients did.= ) --> This Linux client follows the exclusive create with a Setattr, but only= for the "mode" attribute, leaving the create_verifier in the atime field. I can think of two ways to fix this: 1 - Make the Setattr set atime whenever it sets any other attribute. --> This would result in atime being set for changes to the file's met= adata, which is not what atime is supposed to do. (Yuck!) 2 - For NFSv4, store the create_verifier in an extended attribute instead o= f atime. --> I think this would work, but it would imply that only file systems= that support extended attributes (UFS, ZFS, ??) could be exported to NFSv4 cl= ients. Anyone have other ideas w.r.t. how to fix this? Does restricting NFSv4 exports to file systems that support extended attrib= utes sound reasonable? Thanks for any comments w.r.t. this, rick= From owner-freebsd-fs@freebsd.org Sat Apr 15 18:08:03 2017 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 CFC9ED3F97D for ; Sat, 15 Apr 2017 18:08:03 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id 9309716C1 for ; Sat, 15 Apr 2017 18:08:03 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:1198:6f0f:a5bc:fb21]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 13FE19A2 for ; Sat, 15 Apr 2017 21:08:01 +0300 (MSK) Date: Sat, 15 Apr 2017 21:08:10 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <25419193.20170415210810@serebryakov.spb.ru> To: freebsd-fs@freebsd.org Subject: "zfs receive -x" option MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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, 15 Apr 2017 18:08:03 -0000 Hello Freebsd-fs, Here is Illumos ticket about "-x" option for "zfs receive": https://www.illumos.org/issues/2745 It mention, that "As reported by Zender Fufikoff on Illumos ZFS mailing list. This has been done on ZoL and FreeBSD and ported to Nexenta." And here is commit to Nexenta repo which contains referencve to FreeBSD too ("port FreeBSD patch - new zfs recv options support"): https://github.com/Nexenta/illumos-nexenta/commit/21eaf38dbf37deaf21b7d044b8ea5fb699fcff38 But I could not find any traces of this functionality in FreeBSD. Our zfs_main.c https://svnweb.freebsd.org/base/head/cddl/contrib/opensolaris/cmd/zfs/zfs_main.c doesn't contain this code, for example. What happens to this code? It is very useful option, IMHO! -- Best regards, Lev mailto:lev@FreeBSD.org