NFS Reliability .. Work Arounds.. - NFS

This is a discussion on NFS Reliability .. Work Arounds.. - NFS ; This message is of a somewhat technical nature and I'm writing this primarily to solicit ideas from other admins who might have run into these problems. We've had ongoing issues with NFS (Network File System) reliability under Ultra (Sparc) Linux, ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 24

Thread: NFS Reliability .. Work Arounds..

  1. NFS Reliability .. Work Arounds..


    This message is of a somewhat technical nature and I'm writing this
    primarily to solicit ideas from other admins who might have run into these
    problems.

    We've had ongoing issues with NFS (Network File System) reliability under
    Ultra (Sparc) Linux, mostly Redhat 6.1 and 6.2 systems as Redhat dropped
    support for Sparc after 6.2.

    What will happen is that after some period of up time, typically 1-2
    months although it tends to be sporadic and there will be times when it happens
    several times in a period of a week or two; attempts to access files on an NFS
    mounted partition will hang indefinitely on a particular client, even though
    the server is still alive and successfully serving files to other servers.

    The fact that other servers are still able to access files from the same
    NFS server would suggest a NFS client side problem, HOWEVER, we have both SunOS
    4.1.4 on 32-bit platforms and Linux on 64-bit UltraSparc platforms and BOTH
    machines will occasionally have this problem accessing files from the Linux NFS
    server, but I've never had problems when the server was SunOS, which tends to
    implicate the server side.

    It does appear to be load related; that is these problems tend to happen
    on machines that have a fairly heavy traffic load. The lighter machines never
    seem to hang.

    Once in this hung state, re-booting the client seems to be the only thing
    that will get things talking again. I've tried killing and restarting NFSD's,
    umounting and mounting NFS partitions, etc, and nothing else has worked.

    A fix for this NFS problem would be much appreciated, but thus far I've
    been unable to locate a problem that seems to fit this description with Google
    let alone a fix for this problem. I can't think of what would be unique to
    our environment.

    I am still running a 2.2.26 kernel, I've tried 2.4.x kernels and
    universally they've been significantly less stable on busy UltraSparc boxes
    than 2.2.x and I haven't even been able to get 2.6.x to compile in UltraSparc.

    If this sounds familiar to anyone, and you've got a fix, I'd much
    appreciate a note on what the magic incantation is. Also, these machines are
    mostly single CPU (with a couple exceptions but the SMP machines aren't having
    any more issues than the single CPU boxes) and most have the low-latency patch
    installed, but the NFS server does not (because the low latency patch is
    incompatible with a RAID patches needed with 2.2.x).

    -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
    Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
    Knowledgable human assistance, not telephone trees or script readers.
    See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.


  2. Re: NFS Reliability .. Work Arounds..

    In article ,
    Nanook wrote:
    >
    > This message is of a somewhat technical nature and I'm writing this
    >primarily to solicit ideas from other admins who might have run into these
    >problems.


    Well, that makes a change :-)

    > We've had ongoing issues with NFS (Network File System) reliability under
    >Ultra (Sparc) Linux, mostly Redhat 6.1 and 6.2 systems as Redhat dropped
    >support for Sparc after 6.2.
    >
    > What will happen is that after some period of up time, typically 1-2
    >months although it tends to be sporadic and there will be times when it happens
    >several times in a period of a week or two; attempts to access files on an NFS
    >mounted partition will hang indefinitely on a particular client, even though
    >the server is still alive and successfully serving files to other servers.


    I have seen that on many other Unices over a period of years, including
    on other Linux variants. The root cause is that NFS error recovery is
    a bit of a hack (like most Internet protocol error recovery), and it
    tends to go wrong when clients or servers are extended (e.g. by adding
    function, optimising etc.) I have never tracked down the details.

    One key question is whether you are using UDP or TCP. TCP is claimed
    to be a reliable protocol, but it isn't - and every version of TCP that
    I know of has such problems. My experience is that NFS+UDP is more
    reliable than NFS+TCP.

    > The fact that other servers are still able to access files from the same
    >NFS server would suggest a NFS client side problem, HOWEVER, we have both SunOS
    >4.1.4 on 32-bit platforms and Linux on 64-bit UltraSparc platforms and BOTH
    >machines will occasionally have this problem accessing files from the Linux NFS
    >server, but I've never had problems when the server was SunOS, which tends to
    >implicate the server side.


    Yes and no. I know of one TCP failure syndrome that I believe starts
    from either a defect in the RFC or a bug in the Berkeley reference
    implementation that I have seen on IRIX, AIX, Linux, Solaris and OSF/1.
    It is possible that Solaris does something (correctly) that triggers
    that bug, for example.

    > It does appear to be load related; that is these problems tend to happen
    >on machines that have a fairly heavy traffic load. The lighter machines never
    >seem to hang.


    Yup.

    > Once in this hung state, re-booting the client seems to be the only thing
    >that will get things talking again. I've tried killing and restarting NFSD's,
    >umounting and mounting NFS partitions, etc, and nothing else has worked.


    That smells strongly like a transport problem, not an NFS one. Both
    Linux and Solaris have misdesigns where a failure in the transport
    will time out and be retried identically - which means that, if the
    failure is repeatable, it will repeat.

    If you are as old as I am, you might wonder why the code doesn't even
    write a line to syslog indicating that it is retrying for the Nth time,
    but the modern generation of programmers seem to think that I am being
    silly in regarding that as a reasonable expectation.

    > A fix for this NFS problem would be much appreciated, but thus far I've
    >been unable to locate a problem that seems to fit this description with Google
    >let alone a fix for this problem. I can't think of what would be unique to
    >our environment.


    You are VERY unlikely to find one. At best, you will get a bypass.
    Until and unless the software starts diagnosing such failures, it is
    SO hard to track down the bug that almost nobody ever will - especially
    when the failure is in a lower-level component.

    Yes, we did with Solaris - but we have not yet done so with Linux.


    Regards,
    Nick Maclaren.

  3. Re: NFS Reliability .. Work Arounds..

    Nanook writes:

    > If this sounds familiar to anyone, and you've got a fix, I'd much
    >appreciate a note on what the magic incantation is. Also, these machines are
    >mostly single CPU (with a couple exceptions but the SMP machines aren't having
    >any more issues than the single CPU boxes) and most have the low-latency patch
    >installed, but the NFS server does not (because the low latency patch is
    >incompatible with a RAID patches needed with 2.2.x).



    Run Solaris on the UltraSPARC boxes; it has a proper NFS implementation.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  4. Re: NFS Reliability .. Work Arounds..

    In article <43ccc116$0$11062$e4fe514c@news.xs4all.nl>,
    Casper H.S. Dik wrote:
    >Nanook writes:
    >
    >> If this sounds familiar to anyone, and you've got a fix, I'd much
    >>appreciate a note on what the magic incantation is. Also, these machines are
    >>mostly single CPU (with a couple exceptions but the SMP machines aren't having
    >>any more issues than the single CPU boxes) and most have the low-latency patch
    >>installed, but the NFS server does not (because the low latency patch is
    >>incompatible with a RAID patches needed with 2.2.x).

    >
    >Run Solaris on the UltraSPARC boxes; it has a proper NFS implementation.


    Please don't post propaganda. Solaris's NFS is somewhat better than
    Linux's, but it has all of the same flaws.

    If you search on our contract, you will find the foul NFS bug that we
    located. The bug in the Cassini driver has been fixed, but the fault
    in Solaris NFS's error recovery has not. And, as the bug report also
    points out, Solaris is as check- and diagnostic-free as Linux. Damn
    shoddy software engineering, in both cases - just like every other
    Unix I know of (or Microsoft's stuff, for that matter).

    Furthermore, that is only one of the failures I have seen with Solaris's
    NFS. My estimate is that it is perhaps 5-10 times more reliable than
    Linux's, but it is purely a matter of degree, not kind. In terms of
    efficiency, I haven't run comparable enough systems to comment - but
    I am very unimpressed with all of the NFS implementations I have used.


    Regards,
    Nick Maclaren.

  5. Re: NFS Reliability .. Work Arounds..

    nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

    >Please don't post propaganda. Solaris's NFS is somewhat better than
    >Linux's, but it has all of the same flaws.


    Running software which is no longer maintained with an old
    (and known to be really crappy NFS implementation) does not make
    any sense at all.

    >If you search on our contract, you will find the foul NFS bug that we
    >located. The bug in the Cassini driver has been fixed, but the fault
    >in Solaris NFS's error recovery has not. And, as the bug report also
    >points out, Solaris is as check- and diagnostic-free as Linux. Damn
    >shoddy software engineering, in both cases - just like every other
    >Unix I know of (or Microsoft's stuff, for that matter).


    Diagnostics are an extremely difficult art to master; with Solaris 10
    we're delivering the framework which allows software to digest and
    handle diagnostics in a generic manner.

    Without such frameworks diagnostics are useless because there
    are either too many (transient errors provoking diagnostics) or
    far too many (repeatable problems causing repeatable diagnostics)

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  6. Re: NFS Reliability .. Work Arounds..

    In article , nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
    > I have seen that on many other Unices over a period of years, including
    > on other Linux variants. The root cause is that NFS error recovery is
    > a bit of a hack (like most Internet protocol error recovery), and it
    > tends to go wrong when clients or servers are extended (e.g. by adding
    > function, optimising etc.) I have never tracked down the details.
    >
    > One key question is whether you are using UDP or TCP. TCP is claimed
    > to be a reliable protocol, but it isn't - and every version of TCP that
    > I know of has such problems. My experience is that NFS+UDP is more
    > reliable than NFS+TCP.


    Running UDP.

    Thanks for some explanation.

    With respect to the other replies saying, run Solaris on Sparc,
    while it's true that the Solaris implimentation of NFS seems to work,
    that is never have any problems if the SERVER is Solaris; hardly anything
    else does and it leaves one locked into a hardware platform which I do
    not want to be.

    --
    -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
    Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
    Knowledgable human assistance, not telephone trees or script readers.
    See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.

  7. Re: NFS Reliability .. Work Arounds..

    nanook@eskimo.com (Nanook) writes:

    > With respect to the other replies saying, run Solaris on Sparc,
    >while it's true that the Solaris implimentation of NFS seems to work,
    >that is never have any problems if the SERVER is Solaris; hardly anything
    >else does and it leaves one locked into a hardware platform which I do
    >not want to be.


    Solaris does not leave you locked to a hardware platform.

    Solaris runs and is supported on SPARC and x86/amd64.
    (And available for free download from www.sun.com)

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  8. Re: NFS Reliability .. Work Arounds..

    In article <43ce2120$0$11064$e4fe514c@news.xs4all.nl>,
    Casper H.S. Dik wrote:
    >nanook@eskimo.com (Nanook) writes:
    >
    >> With respect to the other replies saying, run Solaris on Sparc,
    >>while it's true that the Solaris implimentation of NFS seems to work,
    >>that is never have any problems if the SERVER is Solaris; hardly anything
    >>else does and it leaves one locked into a hardware platform which I do
    >>not want to be.

    >
    >Solaris does not leave you locked to a hardware platform.
    >
    >Solaris runs and is supported on SPARC and x86/amd64.
    >(And available for free download from www.sun.com)


    Perhaps he wants to escape from both of those? :-)

    Since it has been ported to both of those, I doubt that there is any
    restriction preventing it being ported to System/390, PowerPC or
    most of the other Linux platforms. Porting it to IA64 might be a wee
    bit hairy, of course ....

    Speaking as a neutral observer, using Solaris as a basis for a NFS
    server is a very plausible strategy. While it does have exactly the
    same faults as Linux for that, its NFS server RAS is enough better
    than Linux's that any responsible system administrator should at
    least consider it. We don't currently use Solaris on x86/amd64 for
    major NFS serving, but are definitely considering the option.


    Regards,
    Nick Maclaren.

  9. Re: NFS Reliability .. Work Arounds..

    Nick Maclaren wrote:

    > I have seen that on many other Unices over a period of years, including
    > on other Linux variants. The root cause is that NFS error recovery is
    > a bit of a hack (like most Internet protocol error recovery), and it
    > tends to go wrong when clients or servers are extended (e.g. by adding
    > function, optimising etc.) I have never tracked down the details.


    If you have a stable implementation, NFSv4 removes virtually all
    the protocol holes we have in previous versions. Most notably
    the locking protocol actually works.

    > One key question is whether you are using UDP or TCP. TCP is claimed
    > to be a reliable protocol, but it isn't - and every version of TCP that
    > I know of has such problems. My experience is that NFS+UDP is more
    > reliable than NFS+TCP.


    NFS does not assume a reliable protocol, and when running over TCP
    there are a number of cases where requests or replies can get
    dropped and/or replayed. Usually when the TCP connection gets
    closed at an inopportune time. But it should still be considerably
    more reliable, implementation bugs notwithstanding (RPC/TCP is
    more complex than RPC/UDP).

    >> Once in this hung state, re-booting the client seems to be the only thing
    >>that will get things talking again. I've tried killing and restarting NFSD's,
    >>umounting and mounting NFS partitions, etc, and nothing else has worked.

    >
    >
    > That smells strongly like a transport problem, not an NFS one. Both
    > Linux and Solaris have misdesigns where a failure in the transport
    > will time out and be retried identically - which means that, if the
    > failure is repeatable, it will repeat.


    It could also be a NIC layer problem. I have seen cases where one
    end or the other will run out of resources or descriptors under
    heavy load. Bad examples include a NIC that under load turns off
    transmit interrupts and then forgets to turn them back on when
    the load subsides. With TCP this can wedge a connection waiting
    for an ACK. UDP may be more forgiving as the upper level RPC
    just gives up quickly and resends, relieving the constipation.

    -David

  10. Re: NFS Reliability .. Work Arounds..

    In article <43ce2120$0$11064$e4fe514c@news.xs4all.nl>, Casper H.S. Dik writes:
    > nanook@eskimo.com (Nanook) writes:
    >
    > > With respect to the other replies saying, run Solaris on Sparc,
    > >while it's true that the Solaris implimentation of NFS seems to work,
    > >that is never have any problems if the SERVER is Solaris; hardly anything
    > >else does and it leaves one locked into a hardware platform which I do
    > >not want to be.

    >
    > Solaris does not leave you locked to a hardware platform.
    >
    > Solaris runs and is supported on SPARC and x86/amd64.
    > (And available for free download from www.sun.com)
    >
    > Casper


    I might want to go to a power PC platform; etc. I want the freedom to
    be able to do that if I wish.

    However, that said I ran Solaris on a server at one time and NFS was
    about the only thing it did reliably and it was slow and sluggish.

    But beyond that I really prefer to minimize the number of different OS's
    in use to make administration easier.

    I was kind of hoping 'linux.help' might be that not 'solaris.advertising'.

    As widespread as Linux is there has to be someone who's dug into this
    issue somewhere.

    --
    -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
    Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
    Knowledgable human assistance, not telephone trees or script readers.
    See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.

  11. Re: NFS Reliability .. Work Arounds..

    On 19 Jan 2006 02:06:20 GMT, nanook@eskimo.com (Nanook) wrote:

    >In article <43ce2120$0$11064$e4fe514c@news.xs4all.nl>, Casper H.S. Dik writes:
    >> nanook@eskimo.com (Nanook) writes:
    >>
    >> > With respect to the other replies saying, run Solaris on Sparc,
    >> >while it's true that the Solaris implimentation of NFS seems to work,
    >> >that is never have any problems if the SERVER is Solaris; hardly anything
    >> >else does and it leaves one locked into a hardware platform which I do
    >> >not want to be.

    >>
    >> Solaris does not leave you locked to a hardware platform.
    >>
    >> Solaris runs and is supported on SPARC and x86/amd64.
    >> (And available for free download from www.sun.com)
    >>
    >> Casper

    >
    > I might want to go to a power PC platform; etc. I want the freedom to
    >be able to do that if I wish.


    Do you require that same freedom from other applications you run? NFS
    should be considered the same way since that is precisely what it
    becomes once implemented.

    >
    > However, that said I ran Solaris on a server at one time and NFS was
    >about the only thing it did reliably and it was slow and sluggish.


    Something must have been misconfigured. I ran Solaris NFS servers for
    many years and they ran quite well. They were very fast too. Sparc
    chips are not the best for today's HPC environments but they move data
    very very fast. Slow and sluggish is not something a properly
    configured Solaris NFS server will be.

    >
    > But beyond that I really prefer to minimize the number of different OS's
    >in use to make administration easier.


    Now that's a worthwhile goal, though very difficult to obtain. So far
    I've managed to keep my NFS environment pristine with only one vendor
    but that's about to change soon. You just can't stop progress....

    >
    > I was kind of hoping 'linux.help' might be that not 'solaris.advertising'.


    Huh?

    >
    > As widespread as Linux is there has to be someone who's dug into this
    >issue somewhere.


    Well, considering both RedHat and Novell (SuSe) admit that the NFSv3
    implementation on their respective Linux' blows goats I would say good
    luck.

    ~F

  12. Re: NFS Reliability .. Work Arounds..


    Faeandar wrote:

    > Well, considering both RedHat and Novell (SuSe) admit that the NFSv3
    > implementation on their respective Linux' blows goats I would say good
    > luck.


    Interesting. Do you have a reference for this?


  13. Re: NFS Reliability .. Work Arounds..

    In article <1137648855.738371.324440@g43g2000cwa.googlegroups. com>,
    Mike Eisler wrote:
    >Faeandar wrote:
    >
    >> Well, considering both RedHat and Novell (SuSe) admit that the NFSv3
    >> implementation on their respective Linux' blows goats I would say good
    >> luck.

    >
    >Interesting. Do you have a reference for this?


    While blowing goats is clearly an ecstatic experience, ecstasy implies
    merely an extreme of sensatation and not the desirability of that
    sensation.

    Could someone more familiar with the use of that term explain which
    sub-culture started it, and precisely what it implies? Yes, I know
    roughly what it means, from this and other uses.


    Regards,
    Nick Maclaren.

  14. Re: NFS Reliability .. Work Arounds..

    In article ,
    David Robinson wrote:
    >Nick Maclaren wrote:
    >
    >> I have seen that on many other Unices over a period of years, including
    >> on other Linux variants. The root cause is that NFS error recovery is
    >> a bit of a hack (like most Internet protocol error recovery), and it
    >> tends to go wrong when clients or servers are extended (e.g. by adding
    >> function, optimising etc.) I have never tracked down the details.

    >
    >If you have a stable implementation, NFSv4 removes virtually all
    >the protocol holes we have in previous versions. Most notably
    >the locking protocol actually works.


    Nah. Perhaps half of them - and that's weighted by impact. Yes,
    I agree that it is a significant improvement.

    The only major hole it introduces is Kerberos - and, yes, Kerberos is
    a bug/hole/whatever at its design level. I have seen Kerberos cause
    transport problems, but it isn't relevant here.

    >> One key question is whether you are using UDP or TCP. TCP is claimed
    >> to be a reliable protocol, but it isn't - and every version of TCP that
    >> I know of has such problems. My experience is that NFS+UDP is more
    >> reliable than NFS+TCP.

    >
    >NFS does not assume a reliable protocol, and when running over TCP
    >there are a number of cases where requests or replies can get
    >dropped and/or replayed. Usually when the TCP connection gets
    >closed at an inopportune time. But it should still be considerably
    >more reliable, implementation bugs notwithstanding (RPC/TCP is
    >more complex than RPC/UDP).


    Not necessarily - that is a common misapprehension with protocols
    generally. There are serious bugs in TCP that do not occur in UDP
    (e.g. "stuck connexions"), and NFS needs extra logic to deal with
    them. Secondly, my belief is that NFS has omitted some of the error
    recovery logic for TCP (on the grounds that it is not needed), and
    this means that some failures that would be got trapped by a test
    for an unrelated failure now cause trouble.

    >> That smells strongly like a transport problem, not an NFS one. Both
    >> Linux and Solaris have misdesigns where a failure in the transport
    >> will time out and be retried identically - which means that, if the
    >> failure is repeatable, it will repeat.

    >
    >It could also be a NIC layer problem. I have seen cases where one
    >end or the other will run out of resources or descriptors under
    >heavy load. Bad examples include a NIC that under load turns off
    >transmit interrupts and then forgets to turn them back on when
    >the load subsides. With TCP this can wedge a connection waiting
    >for an ACK. UDP may be more forgiving as the upper level RPC
    >just gives up quickly and resends, relieving the constipation.


    NIC layer problems ARE transport problems! It is extremely hard to
    tell where in the (multiple) transport layers a problem arises, and
    neither Linux nor Solaris provide any decent mechanisms for a mere
    administrator to do so.


    Regards,
    Nick Maclaren.

  15. Re: NFS Reliability .. Work Arounds..


    Nick Maclaren wrote:
    > In article <1137648855.738371.324440@g43g2000cwa.googlegroups. com>,
    > Mike Eisler wrote:
    > >Faeandar wrote:
    > >
    > >> Well, considering both RedHat and Novell (SuSe) admit that the NFSv3
    > >> implementation on their respective Linux' blows goats I would say good
    > >> luck.

    > >
    > >Interesting. Do you have a reference for this?

    >
    > While blowing goats is clearly an ecstatic experience, ecstasy implies


    Having been born in raised in cattle and hog country, I wouldn't know.

    > merely an extreme of sensatation and not the desirability of that
    > sensation.
    >
    > Could someone more familiar with the use of that term explain which
    > sub-culture started it, and precisely what it implies? Yes, I know
    > roughly what it means, from this and other uses.


    You forgot to indicate that follow ups should go to alt.sex.bestiality

    >
    >
    > Regards,
    > Nick Maclaren.



  16. Re: NFS Reliability .. Work Arounds..


    In article <1137684813.099259.226250@g43g2000cwa.googlegroups. com>,
    "Mike Eisler" writes:
    |>
    |> You forgot to indicate that follow ups should go to alt.sex.bestiality

    True, but my question was serious. I really do NOT know the exact
    meaning of the term, and it meant that I wasn't quite sure what was
    being set about RedHat and SuSe NFS. Specifically:

    Does it imply extreme perversion, mind-boggling properties,
    extreme unpleasantness, or some combination of all three?

    I can imagine any of those being meant about software products,
    and have experience with all of them (in a software context, I
    hasten to add).


    Regards,
    Nick Maclaren.

  17. Re: NFS Reliability .. Work Arounds..


    "Nick Maclaren" wrote in message
    news:dqoeeo$e9n$1@gemini.csx.cam.ac.uk...
    >
    > In article <1137684813.099259.226250@g43g2000cwa.googlegroups. com>,
    > "Mike Eisler" writes:
    > |>
    > |> You forgot to indicate that follow ups should go to alt.sex.bestiality
    >
    > True, but my question was serious. I really do NOT know the exact
    > meaning of the term, and it meant that I wasn't quite sure what was
    > being set about RedHat and SuSe NFS. Specifically:
    >
    > Does it imply extreme perversion, mind-boggling properties,
    > extreme unpleasantness, or some combination of all three?
    >
    > I can imagine any of those being meant about software products,
    > and have experience with all of them (in a software context, I
    > hasten to add).
    >
    >
    > Regards,
    > Nick Maclaren.


    Nick,

    I was more amused by the suggestion of running Solaris x86
    as being a reasonable idea. Yeah right ! Let's see, Linux
    runs on a vast set of configurations and hardware, and
    Solaris runs on what configs ? Before anyone tries that
    solution be very very sure that you have supported hardware,
    as stated in the documentation. It won't take you very long to
    check, as the list is pretty small :-) Out of the 100+ PCs that
    I have, and the storeroom full of various parts, I was able
    to assemble 1 (one) that could boot Solaris, and talk
    over the net. And, even then, it required me to manually
    pump the NIC.
    My opinion: The probability of Solaris running on a
    wide cross-section of hardware is slightly lower than
    the probability of the same hardware running BeOS.
    And once you think you have Solaris running, you may
    find that getting a compiler is somewhat problematic.
    (Even if you pull down GCC, you still have some work
    to do, to get that to work !
    Also, the page cache acts pretty funky when this
    beast is setup as an NFS client. Things that you would
    expect to fit in the page cache don't, and you get the
    opportunity to go find the kernel tunables, and try to
    tune this thing up, so it will play nice.

    Conclusion:
    Solaris on SUN hardware == Good stuff.
    Solaris on PC hardware == Good luck !

    Enjoy,
    Postmaster



  18. Re: NFS Reliability .. Work Arounds..

    > I was more amused by the suggestion of running Solaris x86
    > as being a reasonable idea. Yeah right ! Let's see, Linux
    > runs on a vast set of configurations and hardware, and
    > Solaris runs on what configs ? ...


    Whether or not your comments are correct, they have missed the point.
    The number of systems on which Linux runs, and the ease of using it
    on them, is only half the story.

    The Linux NFS client stabilised enough for even research use only
    a couple of years back, and reports are that the newer features are
    still pretty iffy. Its NFS server still isn't stable and, as I
    posted, is something like 5-10 times less reliable than the Solaris
    one.

    Once you look at the whole picture, the decision becomes a lot less
    clear.


    Regards,
    Nick Maclaren.

  19. Re: NFS Reliability .. Work Arounds..

    "Postmaster" writes:


    > I was more amused by the suggestion of running Solaris x86
    > as being a reasonable idea. Yeah right ! Let's see, Linux
    > runs on a vast set of configurations and hardware, and
    > Solaris runs on what configs ? Before anyone tries that
    > solution be very very sure that you have supported hardware,
    > as stated in the documentation. It won't take you very long to
    > check, as the list is pretty small :-) Out of the 100+ PCs that
    > I have, and the storeroom full of various parts, I was able
    > to assemble 1 (one) that could boot Solaris, and talk
    > over the net. And, even then, it required me to manually
    > pump the NIC.


    Yes, you need to configure your networking ....

    I find that most PCs work under Solaris, certainly under current
    Solaris Express; some hardware doesn't have drivers but the difference
    between Linux and Solaris is vanishing small. The HCL is a poor
    measure of systems actually working.

    > And once you think you have Solaris running, you may
    > find that getting a compiler is somewhat problematic.
    > (Even if you pull down GCC, you still have some work
    > to do, to get that to work !


    A working copy of gcc comes pre-installed with the OS; the
    Sun compiler can be downloaded and installed for free.

    > Also, the page cache acts pretty funky when this
    > beast is setup as an NFS client. Things that you would
    > expect to fit in the page cache don't, and you get the
    > opportunity to go find the kernel tunables, and try to
    > tune this thing up, so it will play nice.


    > Conclusion:
    > Solaris on SUN hardware == Good stuff.
    > Solaris on PC hardware == Good luck !


    It works on most systems; and when it runs, it runs NFS a lot
    better than Linux does.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  20. Re: NFS Reliability .. Work Arounds..

    Nick Maclaren wrote:

    > True, but my question was serious. I really do NOT know the exact
    > meaning of the term, and it meant that I wasn't quite sure what was
    > being set about RedHat and SuSe NFS. Specifically:
    >
    > Does it imply extreme perversion, mind-boggling properties,
    > extreme unpleasantness, or some combination of all three?


    I don't know about anyone else, but I have always heard,
    and used, the term to simply mean something is extremely
    bad. So it would mean that the implementation was so
    bad that it wasn't useful. Or the performance was so
    slow that it was unuseable.

    I have not seen it used to directly imply perversion.
    More likely mind bogglingly bad when compared to
    what is considered acceptable.

    -David

    P.S. If I throw in Nazi, can we end this thread?

+ Reply to Thread
Page 1 of 2 1 2 LastLast