From: "J. Bruce Fields" <bfields@fieldses.org>
To: Wendy Cheng <wcheng@redhat.com>
Cc: chuck.lever@oracle.com, nfs@lists.sourceforge.net,
NeilBrown <neilb-YbfuJp6tym7X/JP9YwkgDA@public.gmane.org>,
Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: [NFS] NFS Digest, Vol 18, Issue 70 (NFS performance problems)
Date: Mon, 3 Dec 2007 17:07:37 -0500 [thread overview]
Message-ID: <20071203220737.GJ28201@fieldses.org> (raw)
In-Reply-To: <475479F6.70101@redhat.com>
On Mon, Dec 03, 2007 at 04:49:42PM -0500, Wendy Cheng wrote:
> J. Bruce Fields wrote:
>> On Mon, Dec 03, 2007 at 04:13:02PM -0500, Wendy Cheng wrote:
>>
>>> Or use cluster (a backup server is quite affordable nowadays) ? Was about
>>> to kick off a new discussion about this ...
>>>
>>> I did a prototype about 4 years ago on 2.4 kernel where the RPC reply
>>> cache (slightly modified to include raw NFS request packets) was mirrored
>>> by backup server (in memory). The reply was delayed to go back to client
>>> until the mirrored reply cache entry was acknowledged by the backup
>>> server. Upon crash, the backup server piggybacked its logic on ext3's
>>> journal recovery code. For reply cache entries not replayed or not
>>> recognized by jbd, nfsd resent the NFS raw requests down to filesystem
>>> just like any new arrived requested. The prototype code was able to gain
>>> at least 70% of the async mode performance without losing the data.
>>>
>>> One of other issues with our current linux-based NFS cluster failover is
>>> also right in this arena - that is, upon failover, the non-idempotent
>>> could introduce stale filehandle errors that have been causing headaches
>>> with some of the applications.
>>>
>>
>> How exactly do the stale filehandles happen?
>>
>
> Unless someone has fixed it .. last time we looked .. one of the causes was
> like this:
>
> A "delete" was successfully executed on one server but before replying to
> client, failover occurred. The retransmitted request was sent to take-over
> server that subsequently couldn't find the file (since the file had gone).
> A stale filehandle (or maybe an EACCESS or EPERM, forgot the details
> though) was returned.
OK, makes sense. But the REMOVE operation takes a filehandle (for a
parent) and a name (the name of the thing to remove), so if it's already
been removed you'd expect something like ENOENT.
--b.
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that nfs@lists.sourceforge.net is being discontinued.
Please subscribe to linux-nfs@vger.kernel.org instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
next prev parent reply other threads:[~2007-12-03 22:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.194659.1195581701.26582.nfs@lists.sourceforge.net>
2007-11-20 20:22 ` [NFS] NFS Digest, Vol 18, Issue 70 (NFS performance problems) Wendy Cheng
[not found] ` <BAY104-W43766F661E50E7FFCDA8EBA7F0-MsuGFMq8XAE@public.gmane.org>
2007-11-20 21:17 ` Peter Staubach
2007-11-20 21:23 ` Wendy Cheng
2007-11-21 16:04 ` Chuck Lever
2007-11-26 3:28 ` Wendy Cheng
2007-11-26 4:41 ` Trond Myklebust
2007-11-26 5:02 ` J. Bruce Fields
[not found] ` <18254.19187.470275.538680@notabene.brown>
[not found] ` <18254.19187.470275.538680-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2007-11-29 5:30 ` Trond Myklebust
[not found] ` <1196314230.7950.42.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2007-11-30 16:27 ` Wendy Cheng
2007-12-03 20:31 ` J. Bruce Fields
2007-12-03 21:13 ` Wendy Cheng
2007-12-03 21:30 ` J. Bruce Fields
2007-12-03 21:38 ` J. Bruce Fields
2007-12-03 21:49 ` Wendy Cheng
2007-12-03 22:07 ` J. Bruce Fields [this message]
2007-11-27 18:40 ` Rui Pedro Mendes Salgueiro
[not found] ` <20071127184050.GA13791-/uZbGGhPd8Gmv2Aub4FSgw@public.gmane.org>
2007-11-28 1:50 ` Chuck Lever
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=20071203220737.GJ28201@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=neilb-YbfuJp6tym7X/JP9YwkgDA@public.gmane.org \
--cc=nfs@lists.sourceforge.net \
--cc=trond.myklebust@fys.uio.no \
--cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox