Reco <recovery...@gmail.com> wrote: > On Fri, 19 Jun 2015 20:38:12 +0200 Sven Hartge <s...@svenhartge.de> wrote:
> What I suspect was happening with your NFS server is the multiple > knfsd threads in D-state (i.e. blocked by iowait by slof MMC card) > *plus* this USB Ethernet interrupts. I'd start with lowering knfsd > count. That would also be my first step. I would lower RPCNFSDCOUNT to 2. >> If the source or destination of the transmitted data is on an USB >> medium it gets even worse because all USB ports share the same root >> port on the SoC. > I'm too lazy to check it, so I'll trust you on this. Data enters the SoC through USB from the ethernet chip and then is pushed out on the same shared bus to the USB disk. This absolutely kills the Pi. >> Besides: I always found the load on Linux NFS servers to be higher >> than on a Samba-Server with equal throughput. I guess the calculation >> of the load is different for the NFS kernel server process than for >> userland fileservices. > I have to trust you on this too. Never bothered myself with inferior > network filesystems (Samba) due to the existence of superior one > (NFS4). Well, if you want to serve files to many different operating systems you cannot always use the tools you want if you are not able to control the protocol the client wants or need to speak. > And, speaking of those network filesystems. Have you tried to use iSCSI > to do whatever you're trying to do with NFS? What about a simple sshfs? sshfs couples the problems of the USB network port with the slow ARM-CPU doing crypto stuff. You won't win any speed records with that combination. Grüße, Sven. -- Sigmentation fault. Core dumped. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6bn4gjrph...@mids.svenhartge.de
