From: Andreas Dilger <adilger@clusterfs.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>,
ext2-devel@lists.sourceforge.net
Cc: Adam Cassar <adam.cassar@netregistry.com.au>
Subject: Re: [Ext2-devel] Re: problems with ext3 fs, kernels up to 2.6.6-rc2
Date: Tue, 25 May 2004 10:58:28 -0600 [thread overview]
Message-ID: <20040525165828.GC2603@schnapps.adilger.int> (raw)
In-Reply-To: <20040520092245.GE24219@schnapps.adilger.int>
On May 20, 2004 03:22 -0600, Andreas Dilger wrote:
> This seems to fix the majority of the problems, although there are still
> some rare failures in the rename test.
>
> ===== fs/ext3/namei.c 1.52 vs edited =====
> --- 1.52/fs/ext3/namei.c Mon May 10 05:25:34 2004
> +++ edited/fs/ext3/namei.c Thu May 20 03:16:43 2004
> @@ -2264,8 +2264,9 @@
> /*
> * ok, that's it
> */
> - retval = ext3_delete_entry(handle, old_dir, old_de, old_bh);
> - if (retval == -ENOENT) {
> + if (le32_to_cpu(old_de->inode) != old_inode->i_ino ||
> + (retval = ext3_delete_entry(handle, old_dir,
> + old_de, old_bh)) == -ENOENT) {
> /*
> * old_de could have moved out from under us.
> */
I isolated the source of the remaining problems. In very rare cases
even with the above patch we could still do the wrong thing. If old_de
is pointing to the newly-added entry (i_ino is the same) we end up
deleting the new entry instead of the old one. It looks as if the
rename never happened. We need to verify that the name we are unlinking
is what we expect.
If is also possible that old_de is pointing to the now-unused space
at the end of a newly-split leaf block, so we still need to try
ext3_delete_entry() (which will skip the stale entry and return ENOENT)
instead of just relying on the inum + name check.
===== fs/ext3/namei.c 1.52 vs edited =====
--- 1.52/fs/ext3/namei.c Mon May 10 05:25:34 2004
+++ edited/fs/ext3/namei.c Thu May 20 19:57:10 2004
@@ -2264,11 +2264,15 @@
/*
* ok, that's it
*/
- retval = ext3_delete_entry(handle, old_dir, old_de, old_bh);
- if (retval == -ENOENT) {
- /*
- * old_de could have moved out from under us.
- */
+ if (le32_to_cpu(old_de->inode) != old_inode->i_ino ||
+ old_de->name_len != old_dentry->d_name.len ||
+ strncmp(old_de->name, old_dentry->d_name.name, old_de->name_len) ||
+ (retval = ext3_delete_entry(handle, old_dir,
+ old_de, old_bh)) == -ENOENT) {
+ /* old_de could have moved from under us during htree split, so
+ * make sure that we are deleting the right entry. We might
+ * also be pointing to a stale entry in the unused part of
+ * old_bh so just checking inum and the name isn't enough. */
struct buffer_head *old_bh2;
struct ext3_dir_entry_2 *old_de2;
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
prev parent reply other threads:[~2004-05-25 16:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-19 10:41 problems with ext3 fs, kernels up to 2.6.6-rc2 Paul P Komkoff Jr
2004-05-19 17:06 ` Andreas Dilger
2004-05-20 6:40 ` Paul P Komkoff Jr
2004-05-20 9:22 ` [Ext2-devel] " Andreas Dilger
2004-05-25 16:58 ` Andreas Dilger [this message]
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=20040525165828.GC2603@schnapps.adilger.int \
--to=adilger@clusterfs.com \
--cc=adam.cassar@netregistry.com.au \
--cc=akpm@osdl.org \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-kernel@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