Loading ...
Sorry, an error occurred while loading the content.

Re: NFS performance and other problems with 5.3 beta

Expand Messages
  • lexj1
    ... Thanks for the post, your a lifesaver! I have been searching for a fix to my slow NFS speeds for most of a day. Adding my partitions to the
    Message 1 of 8 , Jun 9 2:05 AM
      --- In nslu2-linux@yahoogroups.com, "Mike (mwester)" <mwester@...> wrote:
      > t.brinkmann@... wrote:
      > > Hi!
      > >
      > > For quite a while, I've been curious about the benefits of EABI, so I decided to install SlugOS 5.3 beta yesterday. I strictly followed the wiki (http://www.nslu2-linux.org/wiki/SlugOS/InstallandTurnupABasicSlugOSSystem etc.). To cut a long story short - I'm back at SlugOS 4.8. Here's why:
      > >
      > > *NFS performance is considerably worse in 5.3 than in 4.8. In 4.8, my DVB-T STB wrote 2.56 MB/s to a NFS share on the slug, under 5.3 the write rate decreased to a mere 0.86 MB/s which is useless for my purposes.
      > Was the hard drive on the slug mounted with the "sync" option? That's
      > the default when udev mounts the device. Please also provide details on
      > the devices used, and the output from the mount command so we can take a
      > look at this.
      > > *Mount behaviour was stranger than ever. The system itself resided on a memstick which was consistently recognized as /dev/sda1, however, my two HDDs changed back and forth between /dev/sdb1 and /dev/sdc1. That's old news, of course, and so I tried the mount-by-label method described in the wiki. Unfortunately, this lead to each drive being mounted twice - first where the slug wanted it and second were I needed it.
      > The strange behavior was actually SlugOS 4.8 -- it's fixed now! :-)
      > If you don't want the devices automatically mounted for you, you need to
      > blacklist them in /etc/udev/mount.blacklist. That you may not have had
      > to do that in 4.8 was a bug, and not a feature... I looked at trying to
      > turn it into a feature, but it's just not possible to create consistent
      > behavior due to the various ways it is possible to mount devices anymore.
      > A side effect of this auto-mounting is that the default options for
      > things mounted in /media is "sync" -- meaning that it goes really really
      > slowly.
      > > *Samba 3.2.8 is a pain. Although this isn't strictly a slug issue, I assume other people will run into problems as well. For some reason beyond mere authentication (lanman vs. ntlm1 vs. ntlm2), I didn't even see the slug in my network neighbourhood (neither in Vista nor XP nor Win98SE). I've set up Samba including DFS on various platforms before and after reverting to SlugOS 4.8, basic configuration took less than 15 minutes, but in 5.3 I spent about 3 hours until I gave up.
      > Yes. IMO Samba 3.2 is a fabulous step forward for the international
      > data-center servers. It sucks for small devices. To start with, 20+ MB
      > to install. Then it doesn't even work -- you need to install locales,
      > and configure them all.
      > I have it working - of course. But it was truly horrible to get it working.
      > Please complain to the Samba folks. :(
      > > Please don't get me wrong - I truly appreciate the developers' ongoing work and the updated information on http://www.nslu2-linux.org/wiki/SlugOS, but in the first place, I need a working fileserver with straightforward configuration. And yes, I RTFMed - if I didn't, I wouldn't have been able to set up SlugOS 4.8 either.
      > Glad you appreciate it! I'm betting its relatively trivial to get the
      > NFS performance fixed (might even be a side-effect of the lack of a
      > blacklist entry that would do it). If you can share some information,
      > we can take a look at it.
      > > Regards,
      > >
      > > T. Brinkmann
      > Mike (mwester)

      Thanks for the post, your a lifesaver! I have been searching for a fix to my slow NFS speeds for most of a day.

      Adding my partitions to the /etc/udev/mount.blacklist fixed the problem. Now I am getting almost 4MB/s, up from 850 kB/s. Also, after it was fixed the sync vs async doesn't seem to have any appreciable effect on the speed.

    Your message has been successfully submitted and would be delivered to recipients shortly.