From: Boaz Harrosh <bharrosh@panasas.com>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: "Matt W. Benjamin" <matt@linuxbox.com>,
linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: unlink within an open directory stream
Date: Mon, 26 Mar 2012 11:17:18 -0700 [thread overview]
Message-ID: <4F70B2AE.4000504@panasas.com> (raw)
In-Reply-To: <1332609149.25346.12.camel@lade.trondhjem.org>
On 03/24/2012 10:12 AM, Myklebust, Trond wrote:
> On Sat, 2012-03-24 at 12:53 -0400, Matt W. Benjamin wrote:
>> Hi,
>>
>> I don't think anything is. Or, people originally reported the behavior against knfsd.
>>
>> Matt
>
> There is a known issue with ext2/3/4 generating non-unique readdir
> cookies. It rarely hits you when you are creating small directories, but
> it frequently hits you with larger ones. A fix is underway that should
> significantly reduce the frequency of cookie collisions.
>
> Recent NFS clients will actually detect the presence of those cookie
> loops, and log them in the kernel syslog. That would therefore be the
> first thing that I'd check if confronted with this kind of problem.
>
> Cheers
> Trond
>
Trond please look on the bug report links below. It's not the "cookie collisions" case.
It's the new (post RHEL 6.0 Kernel) NFS need for opendir after an unlink.
Now the POSIX man page *does* say that applications must re-opendir after
unlink, but there are some applications who did not read the manual, and since
it works with local filesystems and old nfs, (What Kernel RHEL 6.0 is based on?)
they never noticed the bug and never fixed it.
Could we easily support the broken application by being bug compatible to
old NFS versions?
.i.e Don't require re-opendir after unlink of a file.
There are more examples in the bug reports below but basically bonnie++
does the following:
DIR *d = opendir(".");
dirent *file_ent;
while((file_ent = readdir(d)) != NULL) {
unlink( file_ent->d_name))
}
closedir(d);
where it actually needs to do:
DIR *d = opendir(".");
dirent *file_ent;
while((file_ent = readdir(d)) != NULL) {
unlink( file_ent->d_name))
closedir(d);
d = opendir(".");
}
closedir(d);
But again case one used to work with old NFS. And it looks like
it is not Server dependent. We saw this both with Ganesha as well
as knfsd
<snip>
>> http://bugs.centos.org/view.php?id=5496
>> https://bugzilla.redhat.com/show_bug.cgi?id=789452
Thanks
Boaz
next prev parent reply other threads:[~2012-03-26 18:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <209745840.4.1332606289405.JavaMail.root@thunderbeast.private.linuxbox.com>
2012-03-24 16:34 ` unlink within an open directory stream Matt W. Benjamin
2012-03-24 16:44 ` Myklebust, Trond
2012-03-24 16:53 ` Matt W. Benjamin
2012-03-24 17:12 ` Myklebust, Trond
2012-03-24 17:43 ` Matt W. Benjamin
2012-03-26 18:17 ` Boaz Harrosh [this message]
2012-03-26 18:25 ` Myklebust, Trond
2012-03-26 18:43 ` Boaz Harrosh
2012-03-26 18:55 ` Matt W. Benjamin
2012-03-26 19:01 ` Myklebust, Trond
2012-03-26 19:07 ` Boaz Harrosh
2012-03-30 15:24 ` Peter Staubach
2012-03-30 15:46 ` Myklebust, Trond
2012-03-30 16:46 ` Peter Staubach
2012-03-30 17:10 ` Matt W. Benjamin
2012-03-30 20:17 ` Jeff Layton
2012-04-04 15:35 ` Jeff Layton
2012-04-05 8:45 ` Benny Halevy
[not found] <1598378492.82.1332790088063.JavaMail.root@thunderbeast.private.linuxbox.com>
2012-03-26 19:29 ` Matt W. Benjamin
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=4F70B2AE.4000504@panasas.com \
--to=bharrosh@panasas.com \
--cc=Trond.Myklebust@netapp.com \
--cc=linux-nfs@vger.kernel.org \
--cc=matt@linuxbox.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 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).