From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Vsevolod (Simon) Ilyushchenko" <simonf@cshl.edu>
Cc: nfs@lists.sourceforge.net
Subject: Re: Failover using wackamole?
Date: Mon, 28 Feb 2005 15:34:00 -0500 [thread overview]
Message-ID: <20050228203400.GA22284@fieldses.org> (raw)
In-Reply-To: <42237DE7.9010404@cshl.edu>
On Mon, Feb 28, 2005 at 03:24:07PM -0500, Vsevolod (Simon) Ilyushchenko wrote:
> >>I tried this using NFS 4 nfs-utils-1.0.6-52 from FC3 updates. However,
> >>it still failed with the following error:
> >> ls: reading directory a: Input/output error
> >>and this in the error log on the client:
> >> kernel: RPC: garbage, exit EIO
> >>
> >>Is this a bug or a feature?
> >
> >
> >Hm, there may be a bug there. But in any case v4 isn't going to help
> >you here. It's constructing filehandles in exactly the same was as v3.
>
> Oh. :( Bummer. Thanks, though.
>
> Is there then an official NFS 4 way of doing a transparent failover with
> non-shared storage?
NFSv4 does allow you to designate filehandles as "volatile on
migration", in which case the client can attempt to look up the
filehandles after migration. This would only work if you actually told
the client about the migration (probably using NFSERR_MOVED and
FS_LOCATIONS, both added in v4). If the failover was really
"transparent" to the client, then the client wouldn't be able to tell
there was a migration in the first place, so this wouldn't help. Also,
the Linux client implementation of migration isn't finished yet anyway.
Also of course there are inherent problems with looking up the
filehandles again after migration--if the file that a filehandle refers
to has moved since you originally looked up the file, then looking it up
again under the path you originally got it from isn't going to help.
--b.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
prev parent reply other threads:[~2005-02-28 20:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-28 16:18 Failover using wackamole? Vsevolod (Simon) Ilyushchenko
2005-02-28 19:21 ` J. Bruce Fields
2005-02-28 20:24 ` Vsevolod (Simon) Ilyushchenko
2005-02-28 20:34 ` J. Bruce Fields [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=20050228203400.GA22284@fieldses.org \
--to=bfields@fieldses.org \
--cc=nfs@lists.sourceforge.net \
--cc=simonf@cshl.edu \
/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.