On 9/21/07, Trond Myklebust <[EMAIL PROTECTED]> wrote:
> No. The requirement for 'hard' mounts is not that the server be up all
> the time. The server can go up and down as it pleases: the client can
> happily recover from that.
>
> The requirement is rather that nobody remove it permanently
On 9/21/07, Trond Myklebust [EMAIL PROTECTED] wrote:
No. The requirement for 'hard' mounts is not that the server be up all
the time. The server can go up and down as it pleases: the client can
happily recover from that.
The requirement is rather that nobody remove it permanently before the
No. The requirement for 'hard' mounts is not that the server be up all
the time. The server can go up and down as it pleases: the client can
happily recover from that.
The requirement is rather that nobody remove it permanently before the
application is done with it, and the partition is
Isn't this a strict requirement from client side, asking to guarantee
that a server stays up all the time?
I have seen many cases, where people go and directly change IP of
their NFS filers or servers worrying least about the clients using
them.
Can we get around with some sort of congestion
On Fri, 2007-09-21 at 09:20 -0700, Chakri n wrote:
> Thanks.
>
> I was using flock (BSD locking) and I think the problem should be
> solved if I move my application to use POSIX locks.
Yup.
> And any option to avoid processes waiting indefinitely to free pages
> from NFS requests waiting on
Thanks.
I was using flock (BSD locking) and I think the problem should be
solved if I move my application to use POSIX locks.
And any option to avoid processes waiting indefinitely to free pages
from NFS requests waiting on unresponsive NFS server?
Thanks
--Chakri
On 9/21/07, Trond Myklebust
On Thu, 2007-09-20 at 20:12 -0700, Chakri n wrote:
> Thanks Trond, for clarifying this for me.
>
> I have seen similar behavior when a remote NFS server is not
> available. Many processes wait end up waiting in nfs_release_page. So,
> what will happen if the remote server is not available,
>
On Thu, 2007-09-20 at 20:12 -0700, Chakri n wrote:
Thanks Trond, for clarifying this for me.
I have seen similar behavior when a remote NFS server is not
available. Many processes wait end up waiting in nfs_release_page. So,
what will happen if the remote server is not available,
On Fri, 2007-09-21 at 09:20 -0700, Chakri n wrote:
Thanks.
I was using flock (BSD locking) and I think the problem should be
solved if I move my application to use POSIX locks.
Yup.
And any option to avoid processes waiting indefinitely to free pages
from NFS requests waiting on
Thanks.
I was using flock (BSD locking) and I think the problem should be
solved if I move my application to use POSIX locks.
And any option to avoid processes waiting indefinitely to free pages
from NFS requests waiting on unresponsive NFS server?
Thanks
--Chakri
On 9/21/07, Trond Myklebust
Isn't this a strict requirement from client side, asking to guarantee
that a server stays up all the time?
I have seen many cases, where people go and directly change IP of
their NFS filers or servers worrying least about the clients using
them.
Can we get around with some sort of congestion
No. The requirement for 'hard' mounts is not that the server be up all
the time. The server can go up and down as it pleases: the client can
happily recover from that.
The requirement is rather that nobody remove it permanently before the
application is done with it, and the partition is
12 matches
Mail list logo
