problem with nfs Client, when 'NFS server not responding' - NFS

This is a discussion on problem with nfs Client, when 'NFS server not responding' - NFS ; Hey There, I have some solaris server's logging data to an nfs mount, distributed by a nfs server. My problem is that if I for some reason, loose my nfs server, I can no longer log in as user oracle, ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: problem with nfs Client, when 'NFS server not responding'

  1. problem with nfs Client, when 'NFS server not responding'

    Hey There,

    I have some solaris server's logging data to an nfs mount, distributed by a
    nfs server.

    My problem is that if I for some reason, loose my nfs server, I can no
    longer log in as user oracle, - plus the server is performing badly.

    The solution to this is to get the nfs server up running, - and umount my
    nfs client mountpoint. However this is not a nice approach since if I for
    some reason looses the server I will have problems an all my nfs client's. I
    have tried to set mount option retry=0, - to avoid the nfs client to
    remount, - but it doesn't seem to solve the problem. Hope someone will be
    able to provide me with some additional info, solution to this problem. I am
    running nfs, thats default ships with Solaris 5.8.

    Thanks

    /Tommy



  2. Re: problem with nfs Client, when 'NFS server not responding'

    "Tommy Henriksen" wrote in message news:<3f89502b$0$54783$edfadb0f@dread11.news.tele.dk>...
    > Hey There,
    >
    > I have some solaris server's logging data to an nfs mount, distributed by a
    > nfs server.
    >
    > My problem is that if I for some reason, loose my nfs server, I can no
    > longer log in as user oracle, - plus the server is performing badly.
    >
    > The solution to this is to get the nfs server up running, - and umount my
    > nfs client mountpoint. However this is not a nice approach since if I for
    > some reason looses the server I will have problems an all my nfs client's. I
    > have tried to set mount option retry=0, - to avoid the nfs client to
    > remount, - but it doesn't seem to solve the problem. Hope someone will be
    > able to provide me with some additional info, solution to this problem. I am
    > running nfs, thats default ships with Solaris 5.8.


    First thing you need to do is to isolate your NFS mount from user oracle's
    home directory. (I'm assuming the NFS server for oracle's home directory
    is different than that of the NFS server holding the log files. If npt,
    there's no help for you). You probably
    have the log directory mounted at the top of your tree, say:

    mount server:/export /log

    change this to:

    mount server:/export /log/a

    This way, when user oracle logs in, any "pwd" calls won't hang trying
    to stat() /log.

    Second, you apparently are willing to lose log records in exchange for
    better performance and availability of your "solaris server" application.
    Don't bother plying with mount options. At best, you end up with something
    that is fast that frequently logs incorrectly.

    Instead, modify your "solaris server" application so that it writes
    data to a socket, pipe, or named pipe. The other end of the pipe will be
    a log server. Design the log server so that it has two threads. One
    that reads from the socket or pipe, and one that writes data to the log
    file. Inside your log server, allocate a buffer that is large enouhg to buffer
    enough requests to give you enough time to reboot the dead NFS server
    (you should configure your server so that it reboots automatically when
    it crashes), plus an extra amount for a margin of error. Now, thread 1 reads
    the socket, and if there's room in the buffer, adds to the tail of it.
    If there isn't room, it either throws away the log request, or it picks
    one that is in the buffer to dispose of (which do you want, throwaway old
    log records or throwawat new log records?). Thread 2 de-queues from the head of
    the log buffer, and writes to the log file. Obviously, thread 2 and thread 2
    need to have a way to synchronize each other when the read and modify the
    log buffer. Use posix thread locks, or simply use lockf(). Just make sure
    that threads 1 and 2 don't hold te lock while they are
    reading from the socket or writing to the log file.
    >
    > Thanks
    >
    > /Tommy


  3. Re: problem with nfs Client, when 'NFS server not responding'

    Hey Mike,

    Sorry for the late answer, - I appreciate your answer, - but I have been on
    vacation, - and I haven't had the oppotunity processing your answer before
    this. Here is what I got sofare from your messages ...




    "Mike Eisler" skrev i en meddelelse
    news:b8743f87.0310131602.2394e816@posting.google.c om...
    > "Tommy Henriksen" wrote in message

    news:<3f89502b$0$54783$edfadb0f@dread11.news.tele.dk>...
    > > Hey There,
    > >
    > > I have some solaris server's logging data to an nfs mount, distributed

    by a
    > > nfs server.
    > >
    > > My problem is that if I for some reason, loose my nfs server, I can no
    > > longer log in as user oracle, - plus the server is performing badly.
    > >
    > > The solution to this is to get the nfs server up running, - and umount

    my
    > > nfs client mountpoint. However this is not a nice approach since if I

    for
    > > some reason looses the server I will have problems an all my nfs

    client's. I
    > > have tried to set mount option retry=0, - to avoid the nfs client to
    > > remount, - but it doesn't seem to solve the problem.


    I have tried the same setup on a new server installation, - with my new
    setup I am able to do a umount -f , - but if my NFS server is
    down in case a disaster. I have to manually log in to all my server and do
    umount, - unless I ofcourse do some scripting, - but there must be a better
    way of this ???. The consequence of not doing so is that non super users
    (dba user's) have an extremely slow login on nfs clients (slow->in some
    cases infinity), - compared to a login when nfs server running. However the
    server having mounted the nfs filesystem does not seem to be loaded, -
    neither does the LAN.


    >> Hope someone will be
    > > able to provide me with some additional info, solution to this problem.

    I am
    > > running nfs, thats default ships with Solaris 5.8.

    >
    > First thing you need to do is to isolate your NFS mount from user oracle's
    > home directory. (I'm assuming the NFS server for oracle's home directory
    > is different than that of the NFS server holding the log files. If npt,
    > there's no help for you). You probably
    > have the log directory mounted at the top of your tree, say:
    >
    > mount server:/export /log
    >
    > change this to:
    >
    > mount server:/export /log/a
    >
    > This way, when user oracle logs in, any "pwd" calls won't hang trying
    > to stat() /log.
    >


    I have mounted my export on /usr/local/var/test, - could stat() course the
    login problem when /usr/local/var/test is not responding, - ???

    > Second, you apparently are willing to lose log records in exchange for
    > better performance and availability of your "solaris server" application.
    > Don't bother plying with mount options. At best, you end up with something
    > that is fast that frequently logs incorrectly.
    >
    > Instead, modify your "solaris server" application so that it writes
    > data to a socket, pipe, or named pipe. The other end of the pipe will be
    > a log server. Design the log server so that it has two threads. One
    > that reads from the socket or pipe, and one that writes data to the log
    > file. Inside your log server, allocate a buffer that is large enouhg to

    buffer
    > enough requests to give you enough time to reboot the dead NFS server
    > (you should configure your server so that it reboots automatically when
    > it crashes), plus an extra amount for a margin of error.


    What do I achive when using pipes instead of not, - do I avoid problems with
    possibly stat() ???

    > Now, thread 1 reads
    > the socket, and if there's room in the buffer, adds to the tail of it.
    > If there isn't room, it either throws away the log request, or it picks
    > one that is in the buffer to dispose of (which do you want, throwaway old
    > log records or throwawat new log records?). Thread 2 de-queues from the

    head of
    > the log buffer, and writes to the log file. Obviously, thread 2 and thread

    2
    > need to have a way to synchronize each other when the read and modify the
    > log buffer. Use posix thread locks, or simply use lockf(). Just make sure
    > that threads 1 and 2 don't hold te lock while they are
    > reading from the socket or writing to the log file.
    > >
    > > Thanks
    > >
    > > /Tommy




  4. Re: problem with nfs Client, when 'NFS server not responding'

    Hey Mike,

    Sorry for the late answer, - I appreciate your answer, - but I have been on
    vacation, - and I haven't had the oppotunity processing your answer before
    this. Here is what I got sofare from your messages ...




    "Mike Eisler" skrev i en meddelelse
    news:b8743f87.0310131602.2394e816@posting.google.c om...
    > "Tommy Henriksen" wrote in message

    news:<3f89502b$0$54783$edfadb0f@dread11.news.tele.dk>...
    > > Hey There,
    > >
    > > I have some solaris server's logging data to an nfs mount, distributed

    by a
    > > nfs server.
    > >
    > > My problem is that if I for some reason, loose my nfs server, I can no
    > > longer log in as user oracle, - plus the server is performing badly.
    > >
    > > The solution to this is to get the nfs server up running, - and umount

    my
    > > nfs client mountpoint. However this is not a nice approach since if I

    for
    > > some reason looses the server I will have problems an all my nfs

    client's. I
    > > have tried to set mount option retry=0, - to avoid the nfs client to
    > > remount, - but it doesn't seem to solve the problem.


    I have tried the same setup on a new server installation, - with my new
    setup I am able to do a umount -f , - but if my NFS server is
    down in case a disaster. I have to manually log in to all my server and do
    umount, - unless I ofcourse do some scripting, - but there must be a better
    way of this ???. The consequence of not doing so is that non super users
    (dba user's) have an extremely slow login on nfs clients (slow->in some
    cases infinity), - compared to a login when nfs server running. However the
    server having mounted the nfs filesystem does not seem to be loaded, -
    neither does the LAN.


    >> Hope someone will be
    > > able to provide me with some additional info, solution to this problem.

    I am
    > > running nfs, thats default ships with Solaris 5.8.

    >
    > First thing you need to do is to isolate your NFS mount from user oracle's
    > home directory. (I'm assuming the NFS server for oracle's home directory
    > is different than that of the NFS server holding the log files. If npt,
    > there's no help for you). You probably
    > have the log directory mounted at the top of your tree, say:
    >
    > mount server:/export /log
    >
    > change this to:
    >
    > mount server:/export /log/a
    >
    > This way, when user oracle logs in, any "pwd" calls won't hang trying
    > to stat() /log.
    >


    I have mounted my export on /usr/local/var/test, - could stat() course the
    login problem when /usr/local/var/test is not responding, - ???

    > Second, you apparently are willing to lose log records in exchange for
    > better performance and availability of your "solaris server" application.
    > Don't bother plying with mount options. At best, you end up with something
    > that is fast that frequently logs incorrectly.
    >
    > Instead, modify your "solaris server" application so that it writes
    > data to a socket, pipe, or named pipe. The other end of the pipe will be
    > a log server. Design the log server so that it has two threads. One
    > that reads from the socket or pipe, and one that writes data to the log
    > file. Inside your log server, allocate a buffer that is large enouhg to

    buffer
    > enough requests to give you enough time to reboot the dead NFS server
    > (you should configure your server so that it reboots automatically when
    > it crashes), plus an extra amount for a margin of error.


    What do I achive when using pipes instead of not, - do I avoid problems with
    possibly stat() ???

    > Now, thread 1 reads
    > the socket, and if there's room in the buffer, adds to the tail of it.
    > If there isn't room, it either throws away the log request, or it picks
    > one that is in the buffer to dispose of (which do you want, throwaway old
    > log records or throwawat new log records?). Thread 2 de-queues from the

    head of
    > the log buffer, and writes to the log file. Obviously, thread 2 and thread

    2
    > need to have a way to synchronize each other when the read and modify the
    > log buffer. Use posix thread locks, or simply use lockf(). Just make sure
    > that threads 1 and 2 don't hold te lock while they are
    > reading from the socket or writing to the log file.
    > >
    > > Thanks
    > >
    > > /Tommy




  5. Re: problem with nfs Client, when 'NFS server not responding'

    Hey Mike,

    Sorry for the late answer, - I appreciate your answer, - but I have been on
    vacation, - and I haven't had the oppotunity processing your answer before
    this. Here is what I got sofare from your messages ...




    "Mike Eisler" skrev i en meddelelse
    news:b8743f87.0310131602.2394e816@posting.google.c om...
    > "Tommy Henriksen" wrote in message

    news:<3f89502b$0$54783$edfadb0f@dread11.news.tele.dk>...
    > > Hey There,
    > >
    > > I have some solaris server's logging data to an nfs mount, distributed

    by a
    > > nfs server.
    > >
    > > My problem is that if I for some reason, loose my nfs server, I can no
    > > longer log in as user oracle, - plus the server is performing badly.
    > >
    > > The solution to this is to get the nfs server up running, - and umount

    my
    > > nfs client mountpoint. However this is not a nice approach since if I

    for
    > > some reason looses the server I will have problems an all my nfs

    client's. I
    > > have tried to set mount option retry=0, - to avoid the nfs client to
    > > remount, - but it doesn't seem to solve the problem.


    I have tried the same setup on a new server installation, - with my new
    setup I am able to do a umount -f , - but if my NFS server is
    down in case a disaster. I have to manually log in to all my server and do
    umount, - unless I ofcourse do some scripting, - but there must be a better
    way of this ???. The consequence of not doing so is that non super users
    (dba user's) have an extremely slow login on nfs clients (slow->in some
    cases infinity), - compared to a login when nfs server running. However the
    server having mounted the nfs filesystem does not seem to be loaded, -
    neither does the LAN.


    >> Hope someone will be
    > > able to provide me with some additional info, solution to this problem.

    I am
    > > running nfs, thats default ships with Solaris 5.8.

    >
    > First thing you need to do is to isolate your NFS mount from user oracle's
    > home directory. (I'm assuming the NFS server for oracle's home directory
    > is different than that of the NFS server holding the log files. If npt,
    > there's no help for you). You probably
    > have the log directory mounted at the top of your tree, say:
    >
    > mount server:/export /log
    >
    > change this to:
    >
    > mount server:/export /log/a
    >
    > This way, when user oracle logs in, any "pwd" calls won't hang trying
    > to stat() /log.
    >


    I have mounted my export on /usr/local/var/test, - could stat() course the
    login problem when /usr/local/var/test is not responding, - ???

    > Second, you apparently are willing to lose log records in exchange for
    > better performance and availability of your "solaris server" application.
    > Don't bother plying with mount options. At best, you end up with something
    > that is fast that frequently logs incorrectly.
    >
    > Instead, modify your "solaris server" application so that it writes
    > data to a socket, pipe, or named pipe. The other end of the pipe will be
    > a log server. Design the log server so that it has two threads. One
    > that reads from the socket or pipe, and one that writes data to the log
    > file. Inside your log server, allocate a buffer that is large enouhg to

    buffer
    > enough requests to give you enough time to reboot the dead NFS server
    > (you should configure your server so that it reboots automatically when
    > it crashes), plus an extra amount for a margin of error.


    What do I achive when using pipes instead of not, - do I avoid problems with
    possibly stat() ???

    > Now, thread 1 reads
    > the socket, and if there's room in the buffer, adds to the tail of it.
    > If there isn't room, it either throws away the log request, or it picks
    > one that is in the buffer to dispose of (which do you want, throwaway old
    > log records or throwawat new log records?). Thread 2 de-queues from the

    head of
    > the log buffer, and writes to the log file. Obviously, thread 2 and thread

    2
    > need to have a way to synchronize each other when the read and modify the
    > log buffer. Use posix thread locks, or simply use lockf(). Just make sure
    > that threads 1 and 2 don't hold te lock while they are
    > reading from the socket or writing to the log file.
    > >
    > > Thanks
    > >
    > > /Tommy




  6. Re: problem with nfs Client, when 'NFS server not responding'

    Hey Mike,

    Sorry for the late answer, - I appreciate your answer, - but I have been on
    vacation, - and I haven't had the oppotunity processing your answer before
    this. Here is what I got sofare from your answer ...




    "Mike Eisler" skrev i en meddelelse
    news:b8743f87.0310131602.2394e816@posting.google.c om...
    > "Tommy Henriksen" wrote in message

    news:<3f89502b$0$54783$edfadb0f@dread11.news.tele.dk>...
    > > Hey There,
    > >
    > > I have some solaris server's logging data to an nfs mount, distributed

    by a
    > > nfs server.
    > >
    > > My problem is that if I for some reason, loose my nfs server, I can no
    > > longer log in as user oracle, - plus the server is performing badly.
    > >
    > > The solution to this is to get the nfs server up running, - and umount

    my
    > > nfs client mountpoint. However this is not a nice approach since if I

    for
    > > some reason looses the server I will have problems an all my nfs

    client's. I
    > > have tried to set mount option retry=0, - to avoid the nfs client to
    > > remount, - but it doesn't seem to solve the problem.


    I have tried the same setup on a new server installation, - with my new
    setup I am able to do a umount -f , - but if my NFS server is
    down in case a disaster. I have to manually log in to all my server and do
    umount, - unless I ofcourse do some scripting, - but there must be a better
    way of this ???. The consequence of not doing so is that non super users
    (dba user's) have an extremely slow login on nfs clients (slow->in some
    cases infinity), - compared to a login when nfs server running. However the
    server having mounted the nfs filesystem does not seem to be loaded, -
    neither does the LAN.


    >> Hope someone will be
    > > able to provide me with some additional info, solution to this problem.

    I am
    > > running nfs, thats default ships with Solaris 5.8.

    >
    > First thing you need to do is to isolate your NFS mount from user oracle's
    > home directory. (I'm assuming the NFS server for oracle's home directory
    > is different than that of the NFS server holding the log files. If npt,
    > there's no help for you). You probably
    > have the log directory mounted at the top of your tree, say:
    >
    > mount server:/export /log
    >
    > change this to:
    >
    > mount server:/export /log/a
    >
    > This way, when user oracle logs in, any "pwd" calls won't hang trying
    > to stat() /log.
    >


    I have mounted my export on /usr/local/var/test, - could stat() course the
    login problem when /usr/local/var/test is not responding, - ???

    > Second, you apparently are willing to lose log records in exchange for
    > better performance and availability of your "solaris server" application.
    > Don't bother plying with mount options. At best, you end up with something
    > that is fast that frequently logs incorrectly.
    >
    > Instead, modify your "solaris server" application so that it writes
    > data to a socket, pipe, or named pipe. The other end of the pipe will be
    > a log server. Design the log server so that it has two threads. One
    > that reads from the socket or pipe, and one that writes data to the log
    > file. Inside your log server, allocate a buffer that is large enouhg to

    buffer
    > enough requests to give you enough time to reboot the dead NFS server
    > (you should configure your server so that it reboots automatically when
    > it crashes), plus an extra amount for a margin of error.


    What do I achive when using pipes instead of not, - do I avoid problems with
    possibly stat() ???

    > Now, thread 1 reads
    > the socket, and if there's room in the buffer, adds to the tail of it.
    > If there isn't room, it either throws away the log request, or it picks
    > one that is in the buffer to dispose of (which do you want, throwaway old
    > log records or throwawat new log records?). Thread 2 de-queues from the

    head of
    > the log buffer, and writes to the log file. Obviously, thread 2 and thread

    2
    > need to have a way to synchronize each other when the read and modify the
    > log buffer. Use posix thread locks, or simply use lockf(). Just make sure
    > that threads 1 and 2 don't hold te lock while they are
    > reading from the socket or writing to the log file.
    > >
    > > Thanks
    > >
    > > /Tommy




+ Reply to Thread