All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wendy Cheng <wcheng@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [RFC 0/3] GFS2 rename race
Date: Tue, 12 Dec 2006 02:53:57 -0500	[thread overview]
Message-ID: <457E6015.10609@redhat.com> (raw)

GFS is reported to have a rename race due to the following calling sequence:

1. vfs do_rename() does path lookup (on directories)
2. vfs do_rename() calls lock_rename() for local locking
3. vfs do_rename() does final file names lookup
4. vfs do_rename() calls GFS's rename function

Since (2) is not cluster-aware, by the time GFS rename is invoked in 
(4), another node could have altered (remove or create) the destination 
file *after* dentry is obtained from (3). The stale dentry will fail the 
final round of inode sanity check. The system call is subsequently 
aborted with ENOENT error. Some applications (mostly mail servers) are 
said to have issues with this - the bug is reported as "error when two 
nodes rename two files to same new name".

One possible (simple) fix for the subject bugzilla is to alter vfs 
lock_rename() to take cluster locks. This requires upstream VFS layer 
change (and it does make the described problem go away). Unfortunately, 
this issue turns out to be much more complicated than the bugzilla has 
reported. It is not so much about rename race but a generic GFS inherent 
design issue. Since GFS never bothers to ask other nodes to refresh 
their dentry upon removing the file (this would create stale dentries 
hanging around in other nodes), each node is responsible to check the 
inode validity for relevant operations (e.g. call gfs_unlink_ok()). This 
implies if we do extra lockings in lock_rename(), it makes no difference 
in gfs_rename() - we still need to check gfs_unlink_ok() and it still 
can return ENOENT error, *if the stale dentries have existed before 
rename system call is invoked*.  So we end up giving up the lock_rename 
fix but go for the following three patches:

Patch 3-1: Yank inode refresh logic out of gfs(x)_get_dentry (currently 
only used by NFS server) so both NFS and rename can share the function.
Patch 3-2:  Fix a possible rename deadlock ordering.
Patch 3-3: The core changes for the described bugzilla.

-- Wendy









             reply	other threads:[~2006-12-12  7:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-12  7:53 Wendy Cheng [this message]
2006-12-13  0:30 ` [Cluster-devel] [RFC 0/3] GFS2 rename race Russell Cattelan
2006-12-13  6:01   ` Wendy Cheng

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=457E6015.10609@redhat.com \
    --to=wcheng@redhat.com \
    /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.