From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 89B2113877A for ; Mon, 28 Jul 2014 13:58:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D9D01E0E1E; Mon, 28 Jul 2014 13:58:47 +0000 (UTC) Received: from smtpq1.gn.mail.iss.as9143.net (smtpq1.gn.mail.iss.as9143.net [212.54.34.164]) by pigeon.gentoo.org (Postfix) with ESMTP id C3B20E0D27 for ; Mon, 28 Jul 2014 13:58:46 +0000 (UTC) Received: from [212.54.34.134] (helo=smtp3.gn.mail.iss.as9143.net) by smtpq1.gn.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1XBlRr-0005Ej-Ky for gentoo-user@lists.gentoo.org; Mon, 28 Jul 2014 15:58:43 +0200 Received: from 53579160.cm-6-8c.dynamic.ziggo.nl ([83.87.145.96] helo=data.antarean.org) by smtp3.gn.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1XBlRr-0000KC-4S for gentoo-user@lists.gentoo.org; Mon, 28 Jul 2014 15:58:43 +0200 Received: from andromeda.localnet (unknown [10.20.13.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by data.antarean.org (Postfix) with ESMTPSA id 78E3A4C for ; Mon, 28 Jul 2014 15:58:19 +0200 (CEST) From: "J. Roeleveld" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] NFS tutorial for the brain dead sysadmin? Date: Mon, 28 Jul 2014 15:58:29 +0200 Message-ID: <5173457.q3mQ4aYvLc@andromeda> Organization: Antarean User-Agent: KMail/4.12.5 (Linux/3.12.21-gentoo-r1; KDE/4.12.5; x86_64; ; ) In-Reply-To: <53D55682.2090607@fastmail.co.uk> References: <065b33b7-e8ad-48d4-8e83-7743b8da7d02@email.android.com> <53D55682.2090607@fastmail.co.uk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Ziggo-spambar: ---- X-Ziggo-spamscore: -4.9 X-Ziggo-spamreport: ALL_TRUSTED=-1,BAYES_00=-1.9,PROLO_TRUST_RDNS=-3,RDNS_DYNAMIC=0.982 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Archives-Salt: ece4d9bd-53f2-4427-9b6b-f2b206f9f31c X-Archives-Hash: ba63a23f011d3d215595963be4f3132d On Sunday, July 27, 2014 08:44:02 PM Kerin Millar wrote: > On 27/07/2014 17:55, J. Roeleveld wrote: > > On 27 July 2014 18:25:24 CEST, "Stefan G. Weichinger" wrote: > >> Am 26.07.2014 04:47, schrieb walt: > >>> So, why did the "broken" machine work normally for more than a year > >>> without rpcbind until two days ago? (I suppose because nfs-utils was > >>> updated to 1.3.0 ?) > >>> > >>> The real problem here is that I have no idea how NFS works, and each > >>> new version is more complicated because the devs are solving problems > >>> that I don't understand or even know about. > >> > >> I double your search for understanding ... my various efforts to set up > >> NFSv4 for sharing stuff in my LAN also lead to unstable behavior and > >> frustration. > >> > >> Only last week I re-attacked this topic as I start using puppet here to > >> manage my systems ... and one part of this might be sharing > >> /usr/portage > >> via NFSv4. One client host mounts it without a problem, the thinkpads > >> don't do so ... just another example ;-) > >> > >> Additional in my context: using systemd ... so there are other > >> (different?) dependencies at work and services started. > >> > >> I'd be happy to get that working in a reliable way. I don't remember > >> unstable behavior with NFS (v2 back then?) when we used it at a company > >> I worked for in the 90s. > >> > >> Stefan > > > > I use NFS for filesharing between all wired systems at home. > > Samba is only used for MS Windows and laptops. > > > > Few things I always make sure are valid: > > - One partition per NFS share > > - No NFS share is mounted below another one > > - I set the version to 3 on the clients > > - I use LDAP for the user accounts to ensure the UIDs and GIDs are > > consistent. > These are generally good recommendations. I'd just like to make a few > observations. > > The problems associated with not observing the first constraint (one > filesystem per export) can be alleviated by setting an explicit fsid. > Doing so can also help to avoid stale handles on the client side if the > backing filesystem changes - something that is very useful in a > production environment. Therefore, I tend to start at 1 and increment > with each newly added export. For example:- > > /export/foo *(async,no_subtree_check,fsid=1) > /export/foo/bar *(async,no_subtree_check,fsid=2) > /export/baz *(async,no_subtree_check,fsid=3) > > If using NFSv3, I'd recommend using "nolock" as a mount option unless > there is a genuine requirement for locks to be co-ordinated. Such locks > are only advisory and are of questionable value. Using nolock simplifies > the requirements on both server and client side, and is beneficial for > performance. > > NFSv3/UDP seems to be limited to a maximum read/write block size of > 32768 in Linux, which will be negotiated by default. Using TCP, the > upper bound will be the value of /proc/fs/nfsd/max_block_size on the > server. Its value may be set to 1048576 at the most. NFSv3/TCP is > problematic so I would recommend NFSv4 if TCP is desired as a transport > protocol. > > NFSv4 provides a useful uid/gid mapping feature that is easier to set up > and maintain than nss_ldap. > > > NFS4 requires all the exports to be under a single foldertree. > > This is a myth: > http://linuxcostablanca.blogspot.co.uk/2012/02/nfsv4-myths-and-legends.html. > Exports can be defined and consumed in the same manner as with NFSv3. When I originally tried NFSv4, it refused to work unless they were all under the same directory. As I dislike that, I decided against using it. That was a long time ago, will revisit that part again later. Interesting link, I wonder how difficult it will be to combine that with Samba 4 and use the Samba AD structure for NFSv4 with either ZFS or BTRFS underneath. -- Joost