From: Jamie Lokier <jamie@shareable.org>
To: Brad Boyer <flar@allandria.com>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
James Morris <jmorris@namei.org>,
linux-nfs@vger.kernel.org, linux-security-module@vger.kernel.org,
Trond Myklebust <Trond.Myklebust@netapp.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
Neil Brown <neilb@suse.de>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/6][v4][RFC] NFSv3: implement extended attribute protocol (XATTR)
Date: Tue, 9 Mar 2010 19:35:45 +0000 [thread overview]
Message-ID: <20100309193545.GE11042@shareable.org> (raw)
In-Reply-To: <20100309070444.GA18216@cynthia.pants.nu>
Brad Boyer wrote:
> On Mon, Mar 08, 2010 at 09:49:27PM -0800, Casey Schaufler wrote:
> > Another is to NFS mount the filesystem back on to the server,
> > in which case James' scheme works just dandy. It's a trick that
> > I've used more than once in the Unix world for this exact purpose.
> > Of course you have to arrange your mount points in advance with
> > malice aforethought, but that's likely something you're used to
> > by now.
>
> That would definitely work, but it's not ideal. Obviously if it's
> being accessed over NFS in one place it probably good enough
> everywhere, but it's overhead that could be eliminated.
As a real example:
Each user has a PC with their own home directory being local, fast
storage, but /home is filled with NFS auto-mounts to everyone else's
home directories, on their individual PCs. The auto-mount map has an
exception, so the local user's home directory is a symlink to the
local storage, instead of an NFS mount.
A scheme like that works very well for occasional access to other
peoples files, and for logging to each other's machines transparently,
yet having fast performance for their own files when using their local
machine.
In an environment where I've used that, forcing local access to go
over local NFS would have destroyed performance for things like big
compiles, running find, git, grep etc. that people do on their own
directories.
-- Jamie
next prev parent reply other threads:[~2010-03-09 19:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.LRH.2.00.1002261457420.25193@tundra.namei.org>
2010-03-08 10:42 ` [PATCH 0/6][v4][RFC] NFSv3: implement extended attribute protocol (XATTR) James Morris
2010-03-08 10:43 ` [PATCH 1/6] NFSv3: convert client to generic xattr API James Morris
2010-03-08 10:44 ` [PATCH 3/6] NFSv3: add client implementation of XATTR protocol James Morris
2010-03-08 10:45 ` [PATCH 4/6] NFSv3: add server " James Morris
2010-03-08 10:46 ` [PATCH 5/6] xattr: add new top level nfsd namespace and implement ext3 support James Morris
[not found] ` <alpine.LRH.2.00.1003082122340.6314-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
2010-03-08 10:43 ` [PATCH 2/6] NFSv3: add xattr API config option for client James Morris
2010-03-08 10:47 ` [PATCH 6/6] NFSv3: Add server namespace support for XATTR protocol implementation James Morris
2010-03-09 3:59 ` [PATCH 0/6][v4][RFC] NFSv3: implement extended attribute protocol (XATTR) Brad Boyer
2010-03-09 5:49 ` Casey Schaufler
[not found] ` <4B95E167.40306-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2010-03-09 7:04 ` Brad Boyer
2010-03-09 19:35 ` Jamie Lokier [this message]
[not found] ` <20100309193545.GE11042-yetKDKU6eevNLxjTenLetw@public.gmane.org>
2010-03-10 3:46 ` Casey Schaufler
2010-03-15 3:19 ` Jamie Lokier
2010-03-15 4:42 ` Casey Schaufler
[not found] ` <4B9DBAB0.5060500-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2010-03-15 14:28 ` Jamie Lokier
[not found] ` <20100315142803.GC15133-yetKDKU6eevNLxjTenLetw@public.gmane.org>
2010-03-15 23:28 ` Casey Schaufler
2010-03-15 23:49 ` Trond Myklebust
2010-03-16 2:31 ` Casey Schaufler
2010-03-17 20:13 ` Eric Paris
2010-03-17 21:23 ` Casey Schaufler
2010-03-09 8:13 ` James Morris
2010-03-13 7:28 ` Brad Boyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100309193545.GE11042@shareable.org \
--to=jamie@shareable.org \
--cc=Trond.Myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=casey@schaufler-ca.com \
--cc=flar@allandria.com \
--cc=jmorris@namei.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).