All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 0/3] NFSD patches to support junctions
Date: Thu, 8 Sep 2011 13:59:46 -0400	[thread overview]
Message-ID: <20110908175946.GA16740@fieldses.org> (raw)
In-Reply-To: <20110902162210.32190.5880.stgit@matisse.1015granger.net>

On Fri, Sep 02, 2011 at 12:38:13PM -0400, Chuck Lever wrote:
> Sometime soon we are going to have easy-to-install user space FedFS
> components.  Here are kernel patches needed to make server-side FedFS
> support work.  Please consider these for the 3.2 kernel.
> 
> The third patch introduces a potentially expensive check to see if
> a junction has been encountered during a mountpoint lookup.  An object
> is a junction iff it has the requisite set of extended attributes.
> However, reading an extended attribute is expensive on some file
> systems.
> 
> To mitigate the cost of this check, junctions always have their sticky
> bit set.  The expensive extended attribute part of the junction test
> is done only if the sticky bit is present.
> 
> Note that today junctions are directories, but someday symlinks might
> also act as junctions (for SMB2 support).  And very few files have the
> sticky bit set.  So we avoid doing a directory test here.
> 
> Also, junctions ostensibly have all zero mode bits to hide their local
> contents.  I don't think the kernel needs to be concerned about the
> permissions as long as the sticky bit is set.  This allows some
> flexibility in how junctions are represented.  However, Jeff thinks
> that having nfsd4_is_junction() also consider mode bits would make the
> expensive part of this test still less frequent.
> 
> Any thoughts about this?

Hm, right, a sticky bit set on a directory is a normal thing.  I thought
Trond's original idea was to check for the sticky bit and not
executable?  Which is a pointless combination so should be very rare.

On a typical system maybe directories with the sticky bit are normally
somewhat rare, but that's a question of policy and there could be cases
where it's common.

--b.

> 
> ---
> 
> Trond Myklebust (3):
>       NFSD: Add a cache for fs_locations information
>       NFSD: Remove the ex_pathname field from struct svc_export
>       NFSD: Cleanup for nfsd4_path()
> 
> 
>  fs/nfsd/export.c            |   15 +-----
>  fs/nfsd/nfs4xdr.c           |  106 ++++++++++++++++++++++++++++++++-----------
>  fs/nfsd/nfsd.h              |    7 +++
>  fs/nfsd/vfs.c               |   16 ++++++
>  include/linux/nfsd/export.h |    2 -
>  5 files changed, 104 insertions(+), 42 deletions(-)
> 
> -- 
> Chuck Lever
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2011-09-08 23:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-02 16:38 [PATCH 0/3] NFSD patches to support junctions Chuck Lever
2011-09-02 16:38 ` [PATCH 1/3] NFSD: Cleanup for nfsd4_path() Chuck Lever
2011-09-08 18:20   ` J. Bruce Fields
2011-09-02 16:38 ` [PATCH 2/3] NFSD: Remove the ex_pathname field from struct svc_export Chuck Lever
2011-09-02 16:38 ` [PATCH 3/3] NFSD: Add a cache for fs_locations information Chuck Lever
2011-09-08 18:21   ` J. Bruce Fields
2011-09-08 18:59     ` Chuck Lever
2011-09-08 17:59 ` J. Bruce Fields [this message]
2011-09-08 18:24   ` [PATCH 0/3] NFSD patches to support junctions J. Bruce Fields
2011-09-08 19:03     ` Chuck Lever
2011-09-08 19:21       ` J. Bruce Fields
2011-09-09  4:47         ` Chuck Lever
2011-09-09 12:06           ` J. Bruce Fields

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=20110908175946.GA16740@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.