linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: linux-cifs-client@lists.samba.org
Cc: linux-fsdevel@vger.kernel.org
Subject: [PATCH 0/3] cifs: make posix codepaths handle hardlinks appropriately (RFC)
Date: Sun,  5 Apr 2009 09:09:18 -0400	[thread overview]
Message-ID: <1238936961-6979-1-git-send-email-jlayton@redhat.com> (raw)

This patchset represents a first draft at making cifs detect hardlinks
at inode creation time.

Currently, cifs has a pretty broken mechanism where all dentries get a
new inode and hardlinks aren't handled at the VFS layer. Presumably this
is because getting inode numbers from windows servers has a performance
cost (separate call to the server).

The problem is that hardlinks aren't detected by the VFS so we have to
try to detect them when we think it will matter. It also means that
there isn't cache consistency between hardlinked inodes.

This patch is intended as a first stab at changing this for inodes on
posix mounts. With posix extensions we generally get a "uniqueid" value
for free from the server when we get inode attributes.

The SNIA docs state that the UniqueId is unique in the scope of the
share, and the MS docs seem to hint that it's per-machine unique value.
Either way, I think it's safe enough not to worry about collisions. With
this change, we'll probably want to make "serverino" the default (and
maybe make it hardcoded on) when posix extensions are enabled.

This set just focuses on the posix extension codepaths. Once I get this
settled, I'll take a crack at fixing up the non-posix codepaths
similarly (they'll be a bit more work -- more functions will need to
be broken up, etc).

The set here seems to work, but there's still more to be done:

1) how to handle an unexpected inode number change (consider a rename or
a delete and recreate event that happens from another client or server).
Right now, I'm not detecting this, but I think we probably need to
consider what to do for it.

2) how to deal with non-posix extensions? When serverino is disabled, I
think we'll want to use iunique() to generate new inode numbers. We
could also consider making that the default as well.

Anyway...the set isn't quite complete, but I'd like to post this to
gather comments and suggestions and as a checkpoint to make sure I'm
doing this reasonably correctly.

Jeff Layton (3):
  cifs: rename cifs_iget to cifs_root_iget
  cifs: add new cifs_iget_unix_basic function
  cifs: add cifs_iget_unix and have readdir codepath use it

 fs/cifs/cifsfs.c    |    2 +-
 fs/cifs/cifsfs.h    |   15 +++++-
 fs/cifs/cifsglob.h  |    1 +
 fs/cifs/cifsproto.h |    8 ++-
 fs/cifs/dir.c       |   12 ++--
 fs/cifs/inode.c     |  158 ++++++++++++++++++++++++++++++++++++--------------
 fs/cifs/readdir.c   |  147 +++++++++++++++++++++++++++++++++++------------
 7 files changed, 251 insertions(+), 92 deletions(-)


             reply	other threads:[~2009-04-05 13:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-05 13:09 Jeff Layton [this message]
2009-04-05 13:09 ` [PATCH 1/3] cifs: rename cifs_iget to cifs_root_iget Jeff Layton
2009-04-05 13:42   ` [linux-cifs-client] " Christoph Hellwig
2009-04-05 13:54     ` Jeff Layton
2009-04-05 13:09 ` [PATCH 2/3] cifs: add new cifs_iget_unix_basic function Jeff Layton
2009-04-08 17:05   ` [linux-cifs-client] " Christoph Hellwig
2009-04-10 13:18     ` Jeff Layton
2009-04-05 13:09 ` [PATCH 3/3] cifs: add cifs_iget_unix and have readdir codepath use it Jeff Layton

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=1238936961-6979-1-git-send-email-jlayton@redhat.com \
    --to=jlayton@redhat.com \
    --cc=linux-cifs-client@lists.samba.org \
    --cc=linux-fsdevel@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 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).