I plug in a USB/ethernet dongle (Belkin) and Linux is quite happy with
it. (Kernel 2.9.29)
I can use scp to copy files of any size from the host. I can also
mount host via NSF but here is the
problem. I can copy only small files via NFS, say below 32K. Anything
bigger and it fails. The dreaded
"not available, still trying" message. Every time.
Now if I use the usb0 as a network device and mount the very same
host, everything is fine.
I believe this must be related to your OS version as I was not able to replicate the issue. I am using Debian, a Linksys USB200M and its identified as eth0. My NFS server is a Freenas box (freebsd).
Perhaps your could provide more details regarding which Linux OS you are running.
mount freenas:/mnt/shares /mnt/shares;mount freenas:/mnt/backup /mnt/backup
beagleboard:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p2 3.4G 839M 2.4G 26% /
tmpfs 113M 0 113M 0% /lib/init/rw
udev 10M 672K 9.4M 7% /dev
tmpfs 113M 0 113M 0% /dev/shm
/dev/sda1 7.5G 4.0K 7.5G 1% /mnt/usb0
freenas:/mnt/shares 1.4T 1.1T 133G 90% /mnt/shares
freenas:/mnt/backup 903G 45G 786G 6% /mnt/backup
beagleboard:~# time cp /mnt/shares/public/Virgin\ Festival\ Montreal\ 2009.jpg .
beagleboard:~# ls -lh
-rw-r--r-- 1 root root 6.9K 2010-03-26 23:15 index.html
-rwxr--r-- 1 root root 6.6M 2010-03-27 11:40 Virgin Festival Montreal 2009.jpg
beagleboard:~# cat /etc/debian_version
beagleboard:~# uname -a
Linux beagleboard 2.6.33-d.1 #1 PREEMPT Tue Mar 2 01:28:57 UTC 2010 armv7l GNU/Linux
eth0 Link encap:Ethernet HWaddr 00:1d:7e:00:d9:ad
inet addr:192.168.201.109 Bcast:192.168.201.255 Mask:255.255.255.0
inet6 addr: fe80::21d:7eff:fe00:d9ad/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:50752 errors:0 dropped:0 overruns:0 frame:0
TX packets:18896 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:12741773 (12.1 MiB) TX bytes:6765558 (6.4 MiB)
I would like to share my experience with you.
I am using this TRENDnet USB to 10/100Mbps Adapter TU2-ET100. My test fixture now has 40 Beagleboards each uses this one to connect to the 24-port D-Link switch. They all run at the same time. All files created for the manufacturing and test are stored in the NFS drive. The Linus OS is in the SD card on mmc0. At the end of each manufacturing & test operation, a 100M bytes tarball will be extracted to a SD card in mmc1 from the NFS drive; I think the tar file and the perl scripts are cached by the OS after the perl script finished its first loop. The extracted tree also contains MD5 checksums. The last task in the script is to validate the MD5 checksums recursively. I think each beagleboard has gone through thousands of SD cards since Feburary.
I think your NFS problem is not caused by the USB-to-Ethernet dongle. I have the older rev. C board that does not have the piggyback 10uF cap on C97. I have seen the ethernet problem and hence caused NFS to fail since I started using it from 2009/9. This problem made me to abandon the idea of putting the rootfs in the NFS drive. I am still using this old board for development on my desk. But, I am aware of this problem and will power cycle the board if it happens. My desktop beagleboard uses the same SD card image as those for manufacturing and test in the fixture. So, the problem is unlikely caused by the system software.
I'm using Ubuntu 8.04 as an NFS server and as I said it works fine if
I use usb0 as an interface.
The reason I suspect the system software is that I can transfer any
size file using scp via the exact same network.
It's only NFS that causes problems.