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 B8C3013877A for ; Mon, 28 Jul 2014 15:29:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 538C5E0DCB; Mon, 28 Jul 2014 15:29:19 +0000 (UTC) Received: from mail-la0-f66.google.com (mail-la0-f66.google.com [209.85.215.66]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EBB59E0D10 for ; Mon, 28 Jul 2014 15:29:17 +0000 (UTC) Received: by mail-la0-f66.google.com with SMTP id mc6so1818749lab.5 for ; Mon, 28 Jul 2014 08:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=QsvRCmC15nGX86V1vA7y1jzLy6oRtKEXSS1U0Ab3QsI=; b=zAfqlZydW23UWT17ep77Ag5VhstDLMqTwcC4ye58Vgw2OiTN8IpLi/HGlCaTzQXMqx 57sClaPof3QUFS30m3IYlhaLUzooTWOwwV28mBpH9Gyf9qvHYzOuBmkB+SfNeq85xxdf qR/ArasihpOGPa0JJIoR697B1uAFd8WgX5gOx0FrUI4CfYWMUEufEmBtJPHP6IzrXHZ2 9qpeSuPv6Am6hjiIfzfuw3CvNaon8cQJBaylqFWfnpGM/xt1NaY7z5eAOF+bPIzIWcoH qu9LCZq7hhaj/n3ZVwBi/Sdp2NE/t+jrIk+JTBtu3QGHAlgrjWWUnt48bPkIqesgb+JM yoyA== 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 X-Received: by 10.152.116.50 with SMTP id jt18mr12172280lab.21.1406561356287; Mon, 28 Jul 2014 08:29:16 -0700 (PDT) Received: by 10.112.13.42 with HTTP; Mon, 28 Jul 2014 08:29:16 -0700 (PDT) In-Reply-To: <5173457.q3mQ4aYvLc@andromeda> References: <065b33b7-e8ad-48d4-8e83-7743b8da7d02@email.android.com> <53D55682.2090607@fastmail.co.uk> <5173457.q3mQ4aYvLc@andromeda> Date: Mon, 28 Jul 2014 19:59:16 +0430 Message-ID: Subject: Re: [gentoo-user] NFS tutorial for the brain dead sysadmin? From: behrouz khosravi To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=001a11c363ecff142a04ff429513 X-Archives-Salt: e0f97226-451f-4ccc-9064-64c8e24213a9 X-Archives-Hash: f0efd0118deb29d53dcf595a4473c34f --001a11c363ecff142a04ff429513 Content-Type: text/plain; charset=UTF-8 Hello every body. I was wondering that is it possible to make portage to sync a only a subset of portage tree. For example I have not installed Gnome and I dont want to sysc command download ebuilds related to this branch. thanks On Mon, Jul 28, 2014 at 6:28 PM, J. Roeleveld wrote: > 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 > > --001a11c363ecff142a04ff429513 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello every body.
I was wondering that is it possible = to make portage to sync a only a subset of portage tree. For example I have= not installed Gnome and I dont want to sysc command download ebuilds relat= ed to this branch.
thanks


On Mon, Jul 28, 2014 at 6:28 PM, J. Roeleveld &= lt;joost@antarean.o= rg> wrote:
On Sunday, July 27, 2014 08:44:02 PM Kerin M= illar wrote:
> On 27/07/2014 17:55, J. Roeleveld wrote:
> > On 27 July 2014 18:25:24 CEST, "Stefan G. Weichinger" &= lt;lists@xunil.at>
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? =C2=A0(I suppose beca= use nfs-utils was
> >>> updated to 1.3.0 ?)
> >>>
> >>> The real problem here is that I have no idea how NFS work= s, and each
> >>> new version is more complicated because the devs are solv= ing 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 behav= ior and
> >> frustration.
> >>
> >> Only last week I re-attacked this topic as I start using pupp= et 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 t= hinkpads
> >> don't do so ... just another example ;-)
> >>
> >> Additional in my context: using systemd ... so there are othe= r
> >> (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 ar= e
> > 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.<= br> > Doing so can also help to avoid stale handles on the client side if th= e
> backing filesystem changes - something that is very useful in a
> production environment. Therefore, I tend to start at 1 and increment<= br> > with each newly added export. For example:-
>
> =C2=A0 =C2=A0/export/foo =C2=A0 =C2=A0 =C2=A0*(async,no_subtree_check,= fsid=3D1)
> =C2=A0 =C2=A0/export/foo/bar =C2=A0*(async,no_subtree_check,fsid=3D2)<= br> > =C2=A0 =C2=A0/export/baz =C2=A0 =C2=A0 =C2=A0*(async,no_subtree_check,= fsid=3D3)
>
> 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 lock= s
> are only advisory and are of questionable value. Using nolock simplifi= es
> 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 transpor= t
> 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.<= br>
When I originally tried NFSv4, it refused to work unless they were all unde= r
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 Sa= mba
4 and use the Samba AD structure for NFSv4 with either ZFS or BTRFS
underneath.

--
Joost


--001a11c363ecff142a04ff429513--