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(-)
next 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).