Professional Web Applications Themes

kernel is always too big.... - Linux Setup, Configuration & Administration

Dave Uhring <daveuhring> wrote: > On Sun, 20 Jul 2003 09:00:32 +0200, Michael Heiming wrote: >> Astonishing, I'm running a few Linux system as NIS/NFS server with >> different clients (Tru64/HP-UX/Solaris/Linux), works like a charm, >> even if you need to set some obscure NFS options, according to the >> Linux NFS HOWTO. > There was a short discussion of the Linux non-compliance with NFS on > [email]freebsd-stablefreebsd.org[/email] a couple of years ago. I have not been able to > locate the particular message, but it was a quite detailed description of > how Linux fails to comply with that ...

  1. #21

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    > On Sun, 20 Jul 2003 09:00:32 +0200, Michael Heiming wrote:
    >> Astonishing, I'm running a few Linux system as NIS/NFS server with
    >> different clients (Tru64/HP-UX/Solaris/Linux), works like a charm,
    >> even if you need to set some obscure NFS options, according to the
    >> Linux NFS HOWTO.
    > There was a short discussion of the Linux non-compliance with NFS on
    > [email]freebsd-stablefreebsd.org[/email] a couple of years ago. I have not been able to
    > locate the particular message, but it was a quite detailed description of
    > how Linux fails to comply with that open standard.
    I've used linux nfs to serve to solaris for years. AFAIR there were a
    few things to set on one side or the other, but they were trivial. The
    technical fact I seem to remember is that linux nfs retransmissions are
    reverse ordered by default from solaris POV. Or solaris retransmits the
    whole transaction, whereas linux retransmits only from the "bad" point
    on. Anyway, there's been no trouble for many years ..
    > I regret not having saved that particular message, but as it appeared at
    > about the same time as I was fighting NFS problems with a Linux NFS server,
    > I recognized that I would have to use either BSD or Solaris. I eventually
    It's not the case.

    Peter
    Peter T. Breuer Guest

  2. #22

    Default Re: kernel is always too big....

    On Sun, 20 Jul 2003 10:18:53 +0200, Peter T. Breuer wrote:
    > Dave Uhring <daveuhring> wrote:
    > I've used linux nfs to serve to solaris for years.
    An amusing reversal of roles.
    > AFAIR there were a
    > few things to set on one side or the other, but they were trivial. The
    > technical fact I seem to remember is that linux nfs retransmissions are
    > reverse ordered by default from solaris POV. Or solaris retransmits the
    > whole transaction, whereas linux retransmits only from the "bad" point
    > on. Anyway, there's been no trouble for many years ..
    Now, which implementation of NFS is a standard, the one from the inventor
    of NFS or the bogus secondary implementator of NFS?
    >> I regret not having saved that particular message, but as it appeared at
    >> about the same time as I was fighting NFS problems with a Linux NFS server,
    >> I recognized that I would have to use either BSD or Solaris. I eventually
    >
    > It's not the case.
    You did not lose my files, I did.

    Dave Uhring Guest

  3. Moderated Post

    Default Re: kernel is always too big....

    Removed by Administrator
    Dave Uhring Guest
    Moderated Post

  4. #24

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    > On Sun, 20 Jul 2003 10:05:32 +0200, Michael Heiming wrote:
    ....
    >> No thanks, Solaris x86 is dog slow and the hw support s. Unless you have
    >> some app that will only run on Solaris/Sparc(64bit), I'd prefer Linux any-day.
    >> ;)
    > The "dog slow" part you have completely in error. Solaris installs with
    > IDE DMA disabled due to the incorrect implementation of such by a few chip
    > manufacturers. ATA DMA can be turned back on with one byte in a config
    > file. In fact, my Duron-1.0GHz Solaris IDE system accesses its drives
    > faster than an Athlon-1.2GHz system with similar drives.
    IDE in a server, Athlon in a server? Haven't seen any Athlon server mobo
    sold by big vendors at all.
    > And I do indeed use Linux on my desktop PeeCee, Slackware-9.0 if it
    > matters. I use Linux there for the simple reason that it is an excellent
    > desktop OS, not a server.
    Now you are trolling, Linux makes a great server OS, probably among the most
    reliable available, running on cheap hardware while delivering superior
    performance. Have you ever compared scp throughput on 100 Mbit-FD,
    Linux <-> Linux against Solaris <-> Solaris?

    --
    Michael Heiming

    Remove +SIGNS and www. if you expect an answer, sorry for
    inconvenience, but I get tons of SPAM
    Michael Heiming Guest

  5. #25

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    > On Sun, 20 Jul 2003 10:18:53 +0200, Peter T. Breuer wrote:
    >> Dave Uhring <daveuhring> wrote:
    >> I've used linux nfs to serve to solaris for years.
    > An amusing reversal of roles.
    It used to be the other way round, but the sun ultrasparcs kept dying.
    No matter how quickly the sun people came round to replace the scsi, or
    the processor, or whatever, the downtime was unacceptable and we
    couldn't keep two of those things hanging around by default, in case
    one died. So we always had a linux "understudy", a P100. Eventually we
    simply let the understudy always have the main role. They're still
    going fine.

    We also initially had netbsd on the P100s, but they were not reliable
    under bsd (code to good for them) and the scsi was only running via
    some isa bridging, and we never could get drivers for any other cards,
    and so on, so we gave up and standardized on linux.

    The few solaris clients (and sgi clients) we still have around work
    fine from the linux nfs servers.
    >> AFAIR there were a
    >> few things to set on one side or the other, but they were trivial. The
    >> technical fact I seem to remember is that linux nfs retransmissions are
    >> reverse ordered by default from solaris POV. Or solaris retransmits the
    >> whole transaction, whereas linux retransmits only from the "bad" point
    >> on. Anyway, there's been no trouble for many years ..
    > Now, which implementation of NFS is a standard, the one from the inventor
    > of NFS or the bogus secondary implementator of NFS?
    I don't know. I have the book on NFS implementation(s), but I have
    never read it. I am always loaning it out to people, many of whom then
    go and teach a course on it. I recall buying the book in a coffee/book
    shop outside of Atlanta.
    >>> I regret not having saved that particular message, but as it appeared at
    >>> about the same time as I was fighting NFS problems with a Linux NFS server,
    >>> I recognized that I would have to use either BSD or Solaris. I eventually
    >>
    >> It's not the case.
    > You did not lose my files, I did.
    Files vanish all the time. That is what backups are for.

    Actually, it's easy to make things kind of disappear under nfs. There
    are several well known tricks that you can find on the web. Nfs does
    not have "strong" unix semantics, and as a result fitting it into a
    unix fs environment results in some cracks at the edges.

    Peter
    Peter T. Breuer Guest

  6. #26

    Default Re: kernel is always too big....

    On Sun, 20 Jul 2003 11:06:51 +0200, Michael Heiming wrote:
    > IDE in a server, Athlon in a server? Haven't seen any Athlon server mobo
    > sold by big vendors at all.
    Personal use with a very light load. And cost was a major factor; the
    machine had an original cost of $372 with 1 40GB HDD.
    > Now you are trolling, Linux makes a great server OS, probably among the most
    > reliable available, running on cheap hardware while delivering superior
    > performance. Have you ever compared scp throughput on 100 Mbit-FD,
    > Linux <-> Linux against Solaris <-> Solaris?
    I have already stated my reason for not considering Linux suitable as a
    server, lack of proper implementation of NFS. Trolls fail to give
    reasons. To answer your question:

    Linux -> Linux
    Slack-9 on Athlon-1.2GHz -> RH-8 on Duron-850MHz, ext3fs

    [tmp]# time scp OOo_1.0.3.1_LinuxIntel_install.tar.gz bar:/tmp
    OOo_1.0.3.1_LinuxIntel_install.tar.gz 100% 70MB 8.1MB/s 00:08

    real 0m9.039s
    user 0m4.550s
    sys 0m0.970s


    Solaris -> Solaris
    Solaris 8 on Duron-1.0GHz -> Solaris 8 on Athlon-1.2GHz

    [/tmp]# time scp OOo_1.0.3.1_LinuxIntel_install.tar.gz desktop:/tmp
    OOo_1.0.3.1_LinuxInt 100% |*************************| 71893 KB 00:07

    real 0m8.319s
    user 0m0.050s
    sys 0m0.960s

    Solaris -> Linux
    Solaris 8 on Duron-1.0GHz -> Slackware-9 on Athlon-1.2GHz XFS

    [/tmp]# time scp OOo_1.0.3.1_LinuxIntel_install.tar.gz desktop:/tmp
    OOo_1.0.3.1_LinuxInt 100% |************************| 71893 KB 00:07

    real 0m8.015s
    user 0m0.110s
    sys 0m0.800s

    Dave Uhring Guest

  7. #27

    Default Re: kernel is always too big....

    On Sun, 20 Jul 2003 12:41:18 +0200, Peter T. Breuer wrote:
    > Dave Uhring <daveuhring> wrote:
    >> An amusing reversal of roles.
    >
    > It used to be the other way round, but the sun ultrasparcs kept dying.
    > No matter how quickly the sun people came round to replace the scsi, or
    > the processor, or whatever, the downtime was unacceptable and we
    > couldn't keep two of those things hanging around by default, in case
    > one died. So we always had a linux "understudy", a P100. Eventually we
    > simply let the understudy always have the main role. They're still
    > going fine.
    Sun did have a rather serious hardware problem a few years back. They do
    not operate their own silicon foundry but rely on outside contractors to
    fab their chips. In, possibly, that case it was IBM who fabbed the cache
    memory chips for SUN and shipped them knowing that the chips were faulty.
    The affected processors were Ultra II 400 & 440 MHz designs.

    Sun's handling of the problem was detestable, even worse than Intel's when
    their npx was found to be faulty.

    But you were faced with what appears to have been hardware problems rather
    than a failure of the OS.
    > The few solaris clients (and sgi clients) we still have around work
    > fine from the linux nfs servers.
    But, as you pointed out, the Linux NFS servers did not work properly
    without some adjustments.
    > I don't know. I have the book on NFS implementation(s), but I have
    > never read it. I am always loaning it out to people, many of whom then
    > go and teach a course on it. I recall buying the book in a coffee/book
    > shop outside of Atlanta.
    Well, IIRC, NFS came from Sun originally and had been in common use long
    before a grad student in Finland started writing his own kernel. It's a
    shame that he did not have access to your book.
    > Files vanish all the time. That is what backups are for.
    To date the only ones vanishing from that Solaris box are the ones I
    deliberately removed. It's a shame that the same could not be said for a
    Linux file server.

    Dave Uhring Guest

  8. #28

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    >>> Linux -> Linux
    >>> Slack-9 on Athlon-1.2GHz -> RH-8 on Duron-850MHz, ext3fs
    >>
    >> Meaningless. You fail to give the parameters of the setup. You'd need
    >> to state the nfs blocksize and fs blocksize, turn off journalling,
    >> decide the fs behavour (sync/async, noatime, etc.) - in fact you'd have
    >> to use the same fs.
    > Of course it's mostly meaningless. But the parameters are whatever each
    > system set as default. BTW, there was no NFS involved here; Michael asked
    The default is not intended to be optimal, but conservative. It used to
    be 1024 bs on linux, which would have been immediately reset to 8192 by
    everyone on a good net. It would be great at 1024 on a bad connection,
    otoh.
    > about scp, not NFS.
    The file system underneath will be a major influence if it's mounted
    sync or is journalling - but anyway you took longer than the 5s between
    bdflushes, so yes the fs is the governer on those measures. To prove
    it (or otherwise ;), do ssh dd if=foo bs=1024 | dd of=/dev/null bs=1024
    and do it twice, so that the input is cached.
    > On the scp to a Solaris system, I used the /tmp directory because
    > journalling is not used there; it is Sun's tmpfs. The write performance
    > on a Solaris 8 UFS with logging enabled is not that great, but then a file
    > server needs to read more often than write.
    > Reportedly, the write performance of a logging UFS is improved in Solaris
    > 9, but I am reluctant to upgrade.
    Peter
    Peter T. Breuer Guest

  9. #29

    Default Re: kernel is always too big....

    Peter T. Breuer <ptboboe.it.uc3m.es> wrote:
    ....
    > It used to be the other way round, but the sun ultrasparcs kept dying.
    > No matter how quickly the sun people came round to replace the scsi, or
    > the processor, or whatever, the downtime was unacceptable and we
    > couldn't keep two of those things hanging around by default, in case
    ....
    The only problems I remember with Sun hw, were always with the bigger
    systems, like E10K. The small systems tend to be very reliable.

    ....
    > The few solaris clients (and sgi clients) we still have around work
    > fine from the linux nfs servers.
    Yep, we keep numerous $$ *nix workstations running with NIS/NFS on Linux
    servers, works like a charm.
    > Files vanish all the time. That is what backups are for.
    Full ack! Lost the most important config file on a LTSP server lately, due
    to rpm update, which wasn't built using the "%config(noreplace) ..." tag.

    Luckily, I could recover the file from backup under a minute, without
    even leaving my chair.
    ;)

    --
    Michael Heiming

    Remove +SIGNS and www. if you expect an answer, sorry for
    inconvenience, but I get tons of SPAM
    Michael Heiming Guest

  10. #30

    Default Re: kernel is always too big....

    On Sun, 20 Jul 2003 19:36:31 +0200, Peter T. Breuer wrote:
    > The default is not intended to be optimal, but conservative. It used to
    > be 1024 bs on linux, which would have been immediately reset to 8192 by
    > everyone on a good net. It would be great at 1024 on a bad connection,
    > otoh.
    Performance is adequate, and conservative is still good. NFS transfers
    run ~11.3MB/sec and there is not enough to be gained with optimization.
    > The file system underneath will be a major influence if it's mounted
    > sync or is journalling - but anyway you took longer than the 5s between
    > bdflushes, so yes the fs is the governer on those measures. To prove
    > it (or otherwise ;), do ssh dd if=foo bs=1024 | dd of=/dev/null bs=1024
    > and do it twice, so that the input is cached.
    As you pointed out, such trivial benchmarks really are meaningless. I did
    that in the first place because of the respect I have for Michael and
    yourself.

    Dave Uhring Guest

  11. #31

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    > On Sun, 20 Jul 2003 20:29:26 +0200, Michael Heiming wrote:
    > scp requires some processor overhead. What speed UltraSPARC? My Ultra
    Unsure, AFAIK Netras have at least 440 MHz, perhaps I should perform
    some tests and write them down.
    >> Overall performance is pretty poor, loaded network or/and cheapo equipment?
    > Network is unloaded and switched; cheapo equipment, you bet. The least
    > expensive which would do the job ;)
    Must be, I even get better speeds at home.
    ;)

    ....
    >> NFS performance depends heavily on the mount options, defaults are rather
    >> conservative on Linux.
    > Conservative is 'good', leading to reliability.
    With cheapo equipment for sure, usually I set r/w size to 32768 which seems to
    deliver best performance. All errors in ifconfig output are 0, no matter how
    much packets have been transfered.

    --
    Michael Heiming

    Remove +SIGNS and www. if you expect an answer, sorry for
    inconvenience, but I get tons of SPAM
    Michael Heiming Guest

  12. #32

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    > On Sun, 20 Jul 2003 22:10:51 +0200, Michael Heiming wrote:
    >> Unsure, AFAIK Netras have at least 440 MHz, perhaps I should perform
    >> some tests and write them down.
    > # /usr/platform/`uname -i`/sbin/prtdiag -v
    > System Configuration: Sun Microsystems sun4u Sun Ultra 1 UPA/SBus (UltraSPARC 167MHz)
    Wow, an Ultra1, this one should be pretty old.
    ;)

    Oops, sure one can use 'prtdiag', meant some tests using scp an write down
    CPU clock, to compare.

    --
    Michael Heiming

    Remove +SIGNS and www. if you expect an answer, sorry for
    inconvenience, but I get tons of SPAM
    Michael Heiming Guest

  13. #33

    Default Re: kernel is always too big....

    On Mon, 21 Jul 2003 08:06:18 -0500, ne... wrote:
    > You'll be happy to know XFS is in Linus' kernel.
    > [09:04:51][work]$ grep XFS /mnt/rh9opt/linux/.config
    > CONFIG_XFS_FS=m
    > # CONFIG_XFS_RT is not set
    > CONFIG_XFS_QUOTA=y
    > CONFIG_XFS_POSIX_ACL=y
    > # CONFIG_VXFS_FS is not set
    Excellent! I had not seen the announcement.

    Dave Uhring Guest

Page 2 of 2 FirstFirst 12

Similar Threads

  1. kernel-source versus kernel-patch
    By Ismael Valladolid Torres in forum Debian
    Replies: 1
    Last Post: July 14th, 06:20 PM
  2. kernel 2.2.x or 2.4.x ?
    By Nicos Gollan in forum Debian
    Replies: 3
    Last Post: July 7th, 07:30 PM
  3. Replies: 15
    Last Post: July 3rd, 05:20 AM
  4. Kernel 2.4.20
    By Abrasive in forum Debian
    Replies: 2
    Last Post: June 30th, 01:50 PM
  5. Kernel 2.5.44
    By Nathan Poznick in forum Debian
    Replies: 3
    Last Post: June 30th, 02:30 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139