From owner-freebsd-net@freebsd.org Sun Dec 4 19:55:14 2016 Return-Path: Delivered-To: freebsd-net@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 9921DC67CDD for ; Sun, 4 Dec 2016 19:55:14 +0000 (UTC) (envelope-from vicepresjoebiden@gmail.com) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 541BD183A for ; Sun, 4 Dec 2016 19:55:14 +0000 (UTC) (envelope-from vicepresjoebiden@gmail.com) Received: by mail-ua0-x233.google.com with SMTP id 12so330240623uas.2 for ; Sun, 04 Dec 2016 11:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=1DRfb77MYetDHoLjPYzw3voutRXE1wvE5SZTb+Yf2JA=; b=rMLnufBzBZYLJSa2tAfp0zqDS2dt28wvNHxg+iupLID8l08XLW83htyVqBXbep0ddZ z4z/OtdJgWUSPMFjU/dYDVCpC0yFlsWA2idga7aPml+NrGejcgiasT38/sHGmdSm65FH dpPnu00LbFaF3lCVpnqRKSi0uVyXKSo4Ssn7xYvqIaqYG5OL4Y3mENQhSDMpSRR/PzRY izKZa3/CLUcBzju5VEpy2/10SC59ceCIbNn0P94Ow3ji1F+CDpbYQM3ym6VDV14MlhD1 51ss9XFzrvwjm0sSswKtHjYFcDLIgYMQ0Ip4VVQ+g+/MKVbMu4GH6mFGznrUnTwUZGDR 8BZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=1DRfb77MYetDHoLjPYzw3voutRXE1wvE5SZTb+Yf2JA=; b=lmX5NejticMIgQ7wt1aK1ikPEgFPJzXa/SNzKEwxK8GgQDHo6awGfZ85jpCL6MnFRU 89UnWNi0fzG/cjb2gUyr0/mVn8boi0eHJzBReJmuA3oHltcpW0EigYeXxq/f90FvNoFP Q5c9rcfVerwKUKwlV4rICR86SOn4OfJhcxhOss8pgL4DkskajIkow8I51cfw+2ASlzSl 52wPATTJsCfJQXkGP3PoI7FIG02jn+9k/VVN5v/IJSFMtgCbw4v33r0bIy7vASohvQ1H NWCgV5wTFhMsLvMSXy2mmJ1tM5pdnHM/OUDIu4JCuP2wdLXr10/S2Py8xF9EXDueCA0v VnLw== X-Gm-Message-State: AKaTC01HpZgPdwmYcVc72qY0KwsiNhZA4RpS6CPFp+wGcrvMQaJiWNFOedQFdAF7Gaq4jdfseu53nDCG+Ot56w== X-Received: by 10.176.80.195 with SMTP id d3mr41907362uaa.125.1480881313202; Sun, 04 Dec 2016 11:55:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.0.103 with HTTP; Sun, 4 Dec 2016 11:55:12 -0800 (PST) In-Reply-To: References: From: Jordan Ladora Date: Sun, 4 Dec 2016 12:55:12 -0700 Message-ID: Subject: Re: File duplication on NFSv4 exported ZFS filesystems to centos client To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 19:55:14 -0000 Ahh!! Thank you! Previously, I tried exporting just the top-level zfs, but then couldn't access the zfs filesystems inside from the client, but listing *all* of them in /etc/exports and only mounting the top-level zfs works perfectly. Just wondering, by the way, if you knew why 'echo' doesn't work on NFS shares? I've not tried it with any other version besides NFSv4, but every other command I've tried on the NFSv4 share works (e.g. cp, rm, cat, nano, rsync, mv, tar) but, for some reason, when I try to 'echo >> ' it does not work. Again, thanks for your help. On Fri, Dec 2, 2016 at 3:04 PM, Rick Macklem wrote: > Jordan Ladora wrote: > >Curious phenomenon of file pseudo-dup with exported ZFS filesystems on > >FreeBSD 10.3-REL NFSv4 export to a centos7 client. > > > > > >*FreeBSD server-* > > > >zpool create zpool_nfsv4 ... > > > >zfs create zpool_nfsv4/zfs2 > > > >zfs create zpool_nfsv4/zfs3 > > > > > >/etc/exports- > > > >V4: / > > > >/zpool_nfsv4 > > > >/zpool_nfsv4/zfs2 > > > >/zpool_nfsv4/zfs3 > > > > > >zfs unshare -a > > > > > >*Centos client-* > > > >mkdir /zpool_nfsv4 > > > >mkdir /zpool_nfsv4_zfs2 > > > >mkdir /zpool_nfsv4_zfs3 > > > >mount -t nfs4 -o rw,intr,hard,proto=tcp,nodev,noexec,nosuid > >10.0.100.100:/zpool_nfsv4 > >/zpool_nfsv4 > > > - I'll call this mount #2. > >mount -t nfs4 -o rw,intr,hard,proto=tcp,nodev,noexec,nosuid > >10.0.100.100:/zpool_nfsv4/zfs2 > >/zpool_nfsv4_zfs2 > - I'll call this mount #3. > >mount -t nfs4 -o rw,intr,hard,proto=tcp,nodev,noexec,nosuid > >10.0.100.100:/zpool_nfsv4/zfs3 > >/zpool_nfsv4_zfs3 > By default (unlike NFSv3) NFSv4 mounts the entire tree of file systems > under the mount point and not just the file system being mounted. > You have two choices: > 1 - Don't do mount #2 or mount #3. The first mount should allow you to > access /zpool_nfsv4/zfs2 and /zpool_nfsv4/zfs3 with the addition > mounts. > OR > 2 - Turn of the "whole tree" behaviour on the server via: > # sysctl vfs.nfsd.mirrormnt=0 > on the FreeBSD server. > (I know, mirrormnt is a weird name for it, but that is what Linux used, > so... > I guess it means "mirror the tree of mounted file systems on the server > to the clients".) > [stuff snipped] > >This seems similar to this (https://serverfault.com/quest > >ions/535318/creating-two-nfs-shares-from-same-server-but- > >when-mounted-both-point-to-same-d) thread with NFSv4 exports on a centos > >server, but I cannot find anything similar to what I see here with a > >FreeBSD NFSv4 server. > What you did definitely had the same file systems mounted multiple times, > so I suspect that is what caused this behaviour. > > rick > > >