<html>
<body>
<font size=3><br>
This string is somewhat missing the point:<br><br>
If a HCA is being used for a vital application service, then one needs an
infrastructure that:<br><br>
(1) Enables the admin to identify whether a service will be impacted and
to what extent<br>
<x-tab> </x-tab>- This is
a very hard problem if the device acts as a consolidated service
point<br>
(2) Enables the admin to migrate services to alternative devices if
available<br>
(3) Enables the admin to prevent migration if no alternative is
present<br>
(4) Translates attention button to notification<br>
(5) Automates much of the above since actual people are expensive<br>
(6) Enables remote service interaction points to recognize the migration
and either adapt or clean up<br><br>
<br>
BTW, whether an application is written to deal with surprise remove isn't
really the issue. All applications and kernel must deal with
failures. How graceful and how transparent to the end user is what
matters.<br><br>
Hence, The above is not unique to IB or really any device. It is an
OS problem and what is required is an OS driven strategy that can support
multiple device types and usage paradigms.<br><br>
Mike<br><br>
<br><br>
<br>
At 08:53 PM 5/3/2005, Caitlin Bestler wrote:<br>
<blockquote type=cite class=cite cite="">On 5/3/05, Tom Duffy
<tduffy@sun.com> wrote:<br>
> On Tue, 2005-05-03 at 09:42 -0700, Caitlin Bestler wrote:<br>
> > Most applications are not written to be able to<br>
> > survice a sudden loss of virtually all of its connections, and
then resume<br>
> > all of the suspended sessions with new connections using new
memory<br>
> > regions.<br>
> <br>
> Most applications *should* be written this way. Especially
since more<br>
> and more people are using unreliable networks (wifi, 3G,
etc.). I can<br>
> see a day where we have RDMA-capable wireless adapters in which
case<br>
> applications will have to be written with the possibility of a
sudden<br>
> loss taken into account.<br>
> <br>
> -tduffy<br>
> <br>
And applications should be prepared for file systems to fail as
well,<br>
but that doesn't mean that the file system shouldn't consider
features<br>
such as journaling that minimize how often the application will be<br>
faced that sort of problem.<br><br>
It would certainly be valid to decide that the effort was not
worthwhile<br>
given the effort required. But such a decision should be made with<br>
full awareness that the notice will enable very few applications to<br>
actually recover when an entire HCA is taken down. If the goal<br>
is to realistically allow applications to confinue functioning after<br>
the loss of multiple ports some more powerful hooks are required.<br>
_______________________________________________<br>
openib-general mailing list<br>
openib-general@openib.org<br>
<a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">
http://openib.org/mailman/listinfo/openib-general</a><br><br>
To unsubscribe, please visit
<a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">
http://openib.org/mailman/listinfo/openib-general</a>
</font></blockquote></body>
</html>