Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Hello All
I am hoping people could give a quick message on their experiences with NFS on the DNS-323.
Let me explain my issues... I have had this DNS 323 for about four years, running the various versions of ffp and the unfs daemons. Without getting into too many details, I am finding that NFS is very slow, but in an inconsistent manner. Just now a 90GB transfer took 9 hours 2.7 MB/s. On the other hand I have seen it move ~400 GB with an average speed of 20 MB/s. Same ffp v0.5 and unfs. When NFS is slow a top command shows me that the CPU is maxed (99%) and RAM at a reasonable 9% but the blinking lights show little HD activity. Thus process is CPU bound.
I was hoping people could share their experiences. Is this problem unique to me?
If others have had similar experience is there a fix to improves this?
I have not tried nfsd version is that better?
Thank you all for any help you provide.
Mike
The DETAILS for those who care:
=====================
For small stuff, simple cp's mv's etc it is fine. However I use it (with rsync) for backup's of 90-200 GB. At different periods it is fast (30 mins) and other times slow (12 hours). Now this isn't an issue of slow one day fast the next. I mean it is fast for 8 months then slow for say 12 months. Then I muck around with something and it is back to fast for a month or two. And I mean relatively fast as in MB/s terms. Let me explain the details:
When I first had it I was running FW 1.04 and ffp 0.3 or 0.4 (I forget it was a long time ago) it was fast enough then so I was happy. Then my automated backup started transfer larger and larger directories. It seemed that once it passed this certain size threshold NFS stalls completely same CPU bound issues.
Then I got fed up, upgraded to FW 1.09 installed the dlink nfs daemon but could never get it to mount so then I upgraded to ffp 0.5 and used that unfs and all of a sudden I was getting that 20MB/s performance I use to have!!! So I was happy
For a bunch of other reasons I decided that I was going to completely re-build the from scratch ie reformat drives, reset FW reinstall ffp. Naturally went straight to ffp 0.5 unfs. However since that rebuild I am getting the crappy hour upon hour. I can not explain it, how is the same software and hardware fast the slow after a simple rebuild?
Unlike before, this has become a problem now I have multiple systems to backup. There simply is not enough hours in the day for each one to get a chance to perform its daily backup.
Let me list the solutions I am already aware of:
1) I know about rsync and transfering things incrementally. rsync it is in full use with all the hidden files excluded
2) I know about the encryption with rsync... in nfs mode rsync simply opens a pipe with no encryption
3) I am running a Gbit LAN
4) I Know about jumbo frame setting for Gbit devices. I doubt this will help considering the process is CPU bound
Thanks again
Offline
Let me add one more thing....
I get this error a lot with unfs:
rsync: failed to set times on "/some/file/name": Stale NFS file handle (116)
Then when I do rsync through ssh I get no errors. So there are definitely some bug...
There was another time when I first upgraded the FW and ffp to 1.09 and 0.5 respectively that the Stale NFS file handle (116) error dissapeared but I would always get a failure to unmount no response from server error. Yet an inspection of /etc/mtab would show nothing mounted.
Again this is all with unfs.
Offline
I share some experience.
I used the ffp unfs but it was not stable the mounts were dropped.
Fonz has made a firmware 1.04 but modified with at true nfs kernel server which could be used reloaded. It worked good no problems.
I now have switched to true debian install. Works good too.
I suggest you try jcards alt-f or if you dare install true debian.
Offline
Thanks bjby for passing that along.... Haven't worked up the courage to try debian...
Offline
Well it seems that there are not a lot of people using unfs on ffp. Well I was working to set up a set of back up processes for my various systems. I was using nfs. The delays and inconsistency and many errors were causing a lot of problems. Let me summarize how one can get around all of this...
1) For small stuff like renaming files and creating a directory nfs works fine
2) For large operations. By large I mean anything that had a large volume of information (GB's) or a large number of files. Do not use nfs.
3) For internal transfers within a single machine use ssh to execute the command so the whole transfer process operates on that machine alone.
4) For large transfers between machines were security is not critical set up an rsync daemon. This will allow for efficient transfers (only differences) without the overhead of encryption.
5) When security is a concern use rsync over ssh. If security isn't an up-most priority you can double the speed using a weaker cipher, the "-c blowfish" option in ssh is the weakest that I am aware of.
Hope this helps others
Take Care
Mike
Last edited by pilotmm (2011-07-02 21:07:50)
Offline