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