NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
performance
1910 Topicschoice of file protocol (AFP vs CIFS vs NFS)
Introduction: What's the right file sharing protocol to use between your computer and your ReadyNAS? You have the choice of at least 3 network filesystem protocols (Apple's AFP, native protocol of Macs; Microsoft's CIFS, also known as SMB, native protocol of Windows but supported by most OSes; Sun's NFS, commonly used with Unix), depending on what OS you run on your computers. If you run Windows, the choice is probably pretty simple -- use CIFS, because Windows doesn't support AFP or NFS out of the box. But if you run Linux, it's roughly equally easy to use CIFS and NFS, and if you run Mac OS X, your computer supports all 3 -- which to choose? The choice comes down to a combination of: - performance -- how fast is it for the work you do? I'll attempt to answer that question here. - features -- does your client OS support it? Does the ReadyNAS fully support it? Does it preserve things you care about, like access permissions, Spotlight metadata, other metadata? I won't touch this topic here either, except to note that the ReadyNAS won't export user shares over NFS, so if you use the ReadyNAS in User security mode, you probably can't use NFS. If you have questions about the methodology or results, or think I did something wrong, please comment! Goals: - I *am* trying to compare the protocols (AFP vs CIFS vs NFS), using OS X as the client and a ReadyNAS as the server. The remote filesystem protocol is the variable in these experiments, for a bunch of different access patterns. - I am *not* trying to measure the raw performance of the ReadyNAS. - I am *not* trying to distinguish whose fault it is (protocol itself, Apple's client implementation, Infrant's server implementation) when something is slow or works poorly. I'm sure you could increase the raw numbers below by using jumbo frames, disabling all journaling, etc on the ReadyNAS, but I'd also expect the relative performance of each protocol would remain the same. Testbed: Client testbed: Mac Pro, OS X 10.4.9, 5GB RAM. Server testbed: ReadyNAS NV, 1GB RAM, 3.01c1-p6 firmware, AFP update, oplocks update. ReadyNAS disk hardware: 4x Seagate Barracuda 7200.10 drives, 400GB each, configured as one X-RAID volume. Network: gigabit ethernet, linksys switch, normal Ethernet MTU (1500). Test methodology: I mounted the same ReadyNAS share via AFP, CIFS and NFS, using mount commands (/sbin/mount_afp, /sbin/mount_nfs, /sbin/mount_smbfs) as root, to mount the "Backup" share on the ReadyNAS as /t/afp, /t/nfs, and t/cifs, respectively. I ran the tests with 'dd', which itself reports the transfer time. I also kept an eye on the network traffic on the OS X client, as measured by Activity Monitor or MenuMeters, during the transfers, to see if it roughly agreed with the throughput calculated by dd; if dd reported a lot of traffic and MenuMeters reported much less, I suspected caching effects on the client (see notes in the individual tests). These are all sequential reads or writes; I'm trying to measure the network filesystem, not the ReadyNAS disk performance. All the results here are extremely reproducible for me, plus or minus a couple percent. In cases where I suspected a caching effect, I ran the same test repeatedly to see what happened, and reported both the cached and uncached results. Test results: Large writes: 1GB, written 1MB at a time. (dd bs=1048576 count=1024 if=/dev/zero of=/t/afp/testfile) AFP: 148.7 sec (7.2 MB/sec) CIFS: 157.7 sec (6.8 MB/sec) NFS: 137.5 sec (7.8 MB/sec) Small writes: 10MB, written 1KB at a time. (dd bs=1024 count=10000 if=/dev/zero of=/t/afp/testfile) AFP: 1.1 sec (9.6 MB/sec) CIFS: 7.5 sec (1.4 MB/sec) NFS: 1.2 sec (8.4 MB/sec) Small reads: 100MB, read 1KB at a time. (dd bs=1024 count=100000 of=/dev/null if=/t/afp/testfile) With this test, I had to unmount and remount the share before each run, because NFS and AFP cache it too well. It's easy to tell the difference, watching traffic on the physical interface though, between a run that's filled from the cache and one that actually goes to the ReadyNAS. AFP: 7.5 sec (13.7 MB/sec). If repeated: 0.5 sec (evidence of local caching). CIFS: 64.0 sec (1.6 MB/sec). If repeated: same. NFS: 7.3 sec (14.0 MB/sec). If repeated: 2.9 sec (evidence of local caching, but not cached as well as AFP). Large reads: 1GB, read 1MB at a time. (dd bs=1048576 count=1024 of=/dev/null if=/t/afp/testfile) AFP: 76.7 sec (14.0 MB/sec). If repeated: 0.48 sec (obviously cached locally) CIFS: 78.6 sec (13.6 MB/sec). If repeated: 78 seconds again (obviously NOT cached locally) NFS: 89.3 sec (12.0 MB/sec). If repeated: 0.53 sec (obviously cached locally) Opening 155 .jpg files (415 MB total) in Preview, via "Select All, Open" in Finder. This is basically a real-world case of mid-side reads, and something I do a lot. local disk: Preview window opens almost immediately, displays sidebar with thumbnails about 3 seconds later, switching between images is almost instant. AFP: Preview window opens after 2 seconds, displays sidebar with thumbnails after 7 seconds; switching between images has barely perceptible lag (about .5 sec). Repeat experiment: Preview window opens and displays thumbnail sidebar almost instantly -- cached on client side. CIFS: Preview window opens after 5 seconds, displays sidebar with thumbnails after 14 seconds; switching between images has notable lag (approx 2 seconds). Repeat experiment: same results (not cached). NFS: Preview window opens after 26 seconds, displays sidebar with thumbnails after 28 seconds; switching between images has barely perceptible lag (approx .5 sec). Repeat experiment: same results (not cached). Editorial comment: The CIFS test (like all tests here) was with the Infrant "ToggleOplocks" addon installed. Without it, performance on this test was downright unusable; the oplock support helps hugely, but still doesn't come close to keeping up with AFP. Conclusions: - AFP: fastest reads, not far behind on writes, caches better. No pathologically bad cases. - CIFS: good for raw I/O throughput (large reads or writes that actually have to go to the server), but bad for small reads/writes, and doesn't cache reads. - NFS: speed is in the middle, no access to user shares. No pathologically bad cases for read performance. Note that the ReadyNAS doesn't support NFS over TCP, so it always uses UDP, so you don't get TCP's path MTU discovery, so if you mismatch MTUs on server and client, you'll get really flaky results. (In general, NFS is the least user-friendly of these protocols on OS X.) In my opinion, AFP is the clear winner; it's cached much better by an OS X client, with significantly better read performance even if it does have to cross the network. Again: If you have questions about the methodology or results, or think I did something wrong, please comment!37KViews0likes18Comments[SOLVED!] Having strange issues using your device, and have antivirus enabled?
We have a few reports of users recently who had issues performing tasks on their device. We root-caused this to be related to the Antivirus engine. We successfully tested and pushed the patch to the update server last night. In order to receive this patch: You must be on ReadyNAS OS 6.9.2 (ReadyNAS OS 6.9.3 will contain the fix natively; we will not fix previous versions). Your ReadyNAS must be connected to the internet. You need Antivirus turned off to apply the patch properly. If you don't mind waiting a bit, your ReadyNAS should automatically download and receive the hotfix within 24-48 hours. Check below how to check if you received the patch before turning Antivirus on again. If you want the apply the patch immediately, reboot your ReadyNAS and wait 15 minutes. Check below how to check if you received the patch before turning Antivirus on again. How to check if you received the patch: Go to your ReadyNAS's Admin Page Go to System > Logs, and click Download All Logs Open the downloaded zip file, and open the file apt-history.log Scroll to the bottom and look for a line that shows an upgrade of readynasos to 6.9.2+1: Start-Date: 2018-01-31 10:55:16 Commandline: apt-get -qq install -fy rn-dictionary freeapp-collection readynasos ca-certificates Upgrade: readynasos:armel (6.9.2, 6.9.2+1) End-Date: 2018-01-31 10:55:18 If you have this, then you have received the patch and you can turn on Antivirus again. Please create a thread if you have any issues. Thanks for your patience. Last updated: Jan 30 2018 @ 7:45 PM PacificSolved33KViews2likes2CommentsCan't connect to web admin panel on ReadyNAS RN102 #24506517
Hi there, After running beautifully for about a year, my RN102 won't let me connect to its admin panel anymore. I've never experienced problems before, I would just go to the local IP address and it worked. Not anymore. Firefox tells me "unable to connect" fairly quickly after I try to connect. IE11 and Chrome produce similar errors. My PC is on Win7 x64. Login on different laptop doesn't work either. - I CAN still reach the shares and folders on the NAS through Windows and Android! Some extra info: - RN102 - upgraded to firmware 6.2.2, after which it wouldn't let me connect - it's ethernet wired to the same router as my PC - I can still successfully ping the IP address and the name I gave the NAS through a command line - turning off Microsofts firewall doens't help - before it 'broke', I was messing with some external apps on it, BarracudaDrive and others. Decided to delete them all, because I didn't get it to work properly. Deleting the apps hung the NAS, I pulled the power and rebooted it. - I also reinstalled the OS using the Reboot sequence with the reset button. After reinstall, connecting to shares in Win7 again works well, but no luck on the admin panel. I'm out of ideas. The one who helps me out will go into my hall of fame. Cheers, AKSolved28KViews0likes17Commentsbtrfs-cleaner frequently stuck at 100% CPU after 6.4.0 upgrade
Since I upgraded my RN102 to 6.4.0 last night I frequently have trouble reaching the admin interface, and my laptop has reported not being able to reach Time Machine. When I login by ssh and use "top", I can see that btrfs-cleaner is stuck at 100% CPU. This can last up to 10 minutes at a time. I only installed about 12h ago and the btrfs-cleaner process already has over 85 minutes of CPU time, that's more than 20 times more than the second most long-running process, readynasd which is at 4 minutes. After a while, btrfs-cleaner drops back to 0% CPU and I can access the NAS normally. My question: is it normal to have such high load of btrfs-cleaner so frequently? Is there any configuration setting that influences this behaviour. I never noticed this problem under the previous version, 6.2.5. Cheers, Joachim In case it matters, my NAS is equipped with 2x 4TB drives in RAID0 with about 40% in use.Solved23KViews1like31CommentsAdmin account locked out - constantly
Hello, I have recently upgraded to 6.10 on my Readynas 212 and have been constantly hampered by not being able to log into the admin account from Chrome. This occurs 90% of the time stating that too many failed attempts have occurred and retry in 5 minutes. This has not occurred in the past before the firmware upgrade. I have setup a recovery password but I am weary and tired on doing this all the time. I can shh into the Nas which I have done and rebooted and once up attempted to log into the units but with the same failed attemp notice. Can something be done to keep this from constantly happening. Thanks for any help. PS. Even using the recovery password produces the same result of failed attempts!!Solved22KViews1like21CommentsDeleting Files and Snapshots does not free up space - UI shows no more snapshots to delete
My ReadyNAS 104, running OS 6.5 was getting tight on space a couple months ago (4 x 4Tb). I deleted all the snapshots, but the UI still shows the snapshots taking up a bunch of space. Fast forward to this month, and I am completely out of space on my NAS. I went in and deleted all of my Windows backup files/folders in the Backup share (4 Tb worth of data). Still have snapshots turned off, and still have no snapshot files. To my surprise, after I deleted the Windows backup files, my UI now shows ALL of that supposedly freed up space is now allocated to "Snapshots." I should have over 4 Tb free at this point, as I only have a little over 6 Tb of files total on the NAS now (of 16 Tb available) but my Readynas is telling me I am out of space. The system is not recognizing that the files have been deleted and that the snapshots are supposed to be deleted. I just completed scrub, rebalance, and defrag. Still I have no free space. I have deleted a large number of files and space was not freed up. I have been deleting the files for over a month. I have read a number of threads on this and tried to delete snapshots but the admin ui indicates that there are no snapshots. I tried deleting snapshots using Timeline - shows *no* snapshots. Tried using recovery mode but there is no Recovery Mode Icon. I Tried browsing to the folder and clicking on "Recover Files" but that also shows *no* snapshots. I used ssh to access the nas. There is no /data/.purge folder that is mentioned on some threads. I use ssh and went to the Share and it appears that there are snapshots for the Share. How can recover space / delete snapshots? I have seen mentioned in some threads that there mighe be a way to delete snapshots that were not correctly deleted.Solved18KViews0likes19CommentsReadyNAS Pro rebooting and resyncing, with file copy hangups and other issues
I have been using a ReadyNAS Pro RNDP6350-100NAS for many years as a home music server (Logitech Media Server) and backup for my PC and data files. Firmware is 4.2.30. It has not been 100% stable for some time, often hanging on a file copy or other processing activity involving about 200 MB or more. I use Windows 7 Professional with its Explorer file manager, and usually have to Ctrl-Alt-Del to get to the Task Manager Applications list to End Process to stop operations that will not complete. The odd thing to me is that after 2-3 rounds of this brute-force intervention at the beginning of a session, my system would run stable for all or most the rest of the day. Then, it would occur again after I haven't used it for a while. The last year or so, it has been close to only 10% remaining space in the volume. I had been using auto spindown after 30 minutes, but recently increased the time to 60 minutes. Now it reboots often and sometimes resyncs, mostly during drive activity but sometimes by itself. I recently expanded two of six disks from 2tb to 4tb, using Seagate ST4000VNB08 Ironwolf drives to replace drives with reallocated sector and command timeout problems. The volume expansion occured as normal after rebuilding with the second 4tb disk, but then it resynced about three times before seeming to be stable. It has since resynced a couple more times in the past few days, but mostly it just keeps rebooting when I try to use it. Having a look at the logs, in the past I think it has been rebooting more than I realize because it is in a separate room and I don't hear it. I don't see any problems with the current set of drives as indicated in the Frontview Smart info tables for each drive. Today I took apart the chassis and unplugged and replugged each of the power supply (PSU) connectors a few times to see if there might be corrosion building up, possibly causing the rebooting and other problems I am experiencing. I also did a thorough vaccum. So far, this has made no difference. I ran four memory test passes yesterday, with no errors for the 3gb memory (both slots in use). I wonder if the ST4000VNB08 drives are supported? They seem to have had the normal Seagate model # updates to the original ST4000VN000 that is listed on the Netgear ReadyNAS approved list, which says this drive "should" work. Regardless, the unit has not been 100% for some time, so I am not sure whether the new drives have created any of the more recent problems. I recently ran an offline file check and data scrub without errors. At this stage, I wonder if it needs a new PSU, or if there is a software fix? I'd rather not get a new unit, but I realize these things don't last forever. Fortunately, I have a recent, nearly 100% backup, spanned across multiple USB drives. Comments and suggestions much appreciated. Thanks! Some Recent Logs: Mon May 22 19:04:27 EDT 2017 System is up. Mon May 22 18:02:04 EDT 2017 System is up. Mon May 22 17:44:59 EDT 2017 System is up. Mon May 22 09:08:42 EDT 2017 RAID sync finished on volume C. Mon May 22 05:54:11 EDT 2017 System is up. Sun May 21 22:14:31 EDT 2017 System is up. Sun May 21 21:39:49 EDT 2017 Volume scan found no errors. Sun May 21 16:48:47 EDT 2017 Rebooting device... Sun May 21 16:48:47 EDT 2017 Please close this browser session and use RAIDar to reconnect to the device. System rebooting... Sun May 21 16:41:50 EDT 2017 Alert settings saved. Sun May 21 16:40:34 EDT 2017 Automatic disk spin-down enabled. Sun May 21 16:21:10 EDT 2017 System is up. Sun May 21 15:51:41 EDT 2017 System is up. Sun May 21 10:44:16 EDT 2017 System is up. Sun May 21 10:40:07 EDT 2017 System is up. Sun May 21 10:28:47 EDT 2017 Update settings saved. Sun May 21 10:25:51 EDT 2017 System is up. Sun May 21 10:14:25 EDT 2017 System is up. Sun May 21 10:09:28 EDT 2017 System is up. Sun May 21 10:02:56 EDT 2017 System is up. Sun May 21 08:51:04 EDT 2017 System is up. Sun May 21 07:39:22 EDT 2017 System is up. Sun May 21 03:24:32 EDT 2017 System is up. Sun May 21 01:17:05 EDT 2017 System is up. Sat May 20 20:03:22 EDT 2017 System is up. Sat May 20 17:20:56 EDT 2017 System is up. Fri May 19 20:34:07 EDT 2017 System is up. Fri May 19 16:31:17 EDT 2017 System is up. Fri May 19 10:37:52 EDT 2017 System is up. Fri May 19 10:36:23 EDT 2017 Rebooting device... Fri May 19 10:36:22 EDT 2017 Please close this browser session and use RAIDar to reconnect to the device. System rebooting... Fri May 19 10:34:43 EDT 2017 RAID sync finished on volume C. Fri May 19 06:00:06 EDT 2017 System is up. Thu May 18 21:59:02 EDT 2017 RAID sync finished on volume C. Thu May 18 17:25:00 EDT 2017 System is up. Thu May 18 10:08:13 EDT 2017 RAID sync finished on volume C. Thu May 18 05:10:41 EDT 2017 Data volume has been successfully expanded to 11101 GB. Thu May 18 05:07:10 EDT 2017 System is up. Thu May 18 05:06:44 EDT 2017 Continuing with volume expansion or migration. Do not interrupt the system during this time. When complete, email notification will be sent to the alert contact list. Thu May 18 00:17:57 EDT 2017 Found space that can be used to expand capacity, expansion process will start during next boot. Thu May 18 00:16:40 EDT 2017 RAID sync finished on volume C. Wed May 17 18:22:26 EDT 2017 RAID sync started on volume C. Wed May 17 18:22:03 EDT 2017 Data volume will be rebuilt with disk 6. Wed May 17 18:21:28 EDT 2017 System is up. Tue May 16 18:35:04 EDT 2017 System is up. Tue May 16 16:41:22 EDT 2017 RAID sync finished on volume C. Tue May 16 10:58:18 EDT 2017 RAID sync started on volume C. Tue May 16 10:57:51 EDT 2017 Data volume will be rebuilt with disk 2. Tue May 16 10:57:17 EDT 2017 System is up. Tue May 16 08:08:03 EDT 2017 System is up. Tue May 16 06:06:15 EDT 2017 System is up. Mon May 15 18:52:14 EDT 2017 System is up. Sun May 14 06:25:03 EDT 2017 Volume C is approaching capacity: 90% used 1018G available Sat May 13 08:41:51 EDT 2017 System is up. Sat May 13 03:55:37 EDT 2017 System is up. Fri May 12 16:37:00 EDT 2017 System is up. Fri May 12 12:13:29 EDT 2017 System is up. Fri May 12 10:07:35 EDT 2017 System is up. Fri May 12 07:45:57 EDT 2017 System is up. Fri May 12 04:26:08 EDT 2017 System is up. Thu May 11 21:06:14 EDT 2017 System is up. Wed May 10 17:30:49 EDT 2017 System is up. Wed May 10 17:30:26 EDT 2017 System Update Status (nas-EA-1F-D1) : Your ReadyNAS device has been updated with a new firmware image. (RAIDiator-x86 4.2.30) Wed May 10 17:28:10 EDT 2017 Rebooting device... Wed May 10 17:28:10 EDT 2017 Please close this browser session and use RAIDar to reconnect to the device. System rebooting... Wed May 10 17:27:03 EDT 2017 Please reboot your ReadyNAS device to continue with the update process. Wed May 10 15:00:28 EDT 2017 System is up. Wed May 10 10:17:26 EDT 2017 System is up. Wed May 10 00:27:16 EDT 2017 System is up. Tue May 9 19:19:40 EDT 2017 System is up. Tue May 9 11:07:50 EDT 2017 System is up. Tue May 9 08:46:17 EDT 2017 System is up. Tue May 9 07:00:36 EDT 2017 System is up. Tue May 9 04:59:55 EDT 2017 System is up. Mon May 8 22:33:24 EDT 2017 System is up. Mon May 8 17:56:04 EDT 2017 System is up. Mon May 8 09:47:25 EDT 2017 System is up. Sun May 7 16:41:28 EDT 2017 System is up. Sun May 7 10:57:18 EDT 2017 System is up. Sun May 7 10:42:22 EDT 2017 System is up. Sun May 7 07:32:23 EDT 2017 System is up. Sun May 7 04:42:23 EDT 2017 System is up. Sun May 7 03:00:22 EDT 2017 System is up. Sun May 7 00:57:39 EDT 2017 System is up. Sat May 6 17:50:16 EDT 2017 System is up. Sat May 6 14:43:12 EDT 2017 System is up. Sat May 6 12:48:14 EDT 2017 System is up. Sat May 6 01:23:45 EDT 2017 Detected increasing command timeouts[10] on disk 6 [ST32000644NS, 9WM7S9FV] in the past 30 days. This often indicates an impending failure. Please be prepared to replace this disk to maintain data redundancy. Fri May 5 19:42:44 EDT 2017 System is up. Fri May 5 17:47:46 EDT 2017 System is up. Fri May 5 07:43:24 EDT 2017 System is up. Thu May 4 13:28:28 EDT 2017 System is up. Thu May 4 13:20:51 EDT 2017 System is up. Thu May 4 13:18:52 EDT 2017 System is up. Thu May 4 12:54:40 EDT 2017 System is up. Thu May 4 04:08:15 EDT 2017 System is up. Thu May 4 01:02:24 EDT 2017 System is up. Wed May 3 19:57:17 EDT 2017 System is up. Wed May 3 04:59:24 EDT 2017 System is up. Wed May 3 02:40:01 EDT 2017 System is up.17KViews0likes25CommentsReadyNAS 314 says "Volume data is degraded", but no errors in logs or disk reports
I have a RN31400. In the web interface, Admin page, System tab, it says "Status: Degraded". It's been saying that for a while. In the Volumes tab, it shows I have one RAID 5 volume with 3 disks and says "Volume is degraded". When I mouse over each of my 3 disks in the Volumes tab, I don't see any problems with any disk (for example, no reallocated sectors, no uncorrectable sectors). In the Logs tab, I see a bunch of "Volume: Volume data is degraded" messages and info about successful operations. There are no warnings or errors other than about volume data being degraded. There are some old antivirus-definition-out-of-date errors but they are very old and don't seem relevant. I also downloaded the logs. I didn't see anything in smart_history.log, systemd-journal.log, or disk_info.log that seemed relevant, other than a repeat of "volume data is degraded". I've looked on the forum about the "volume data is degraded", but usually they have some visible problem with one of the disks, or that there's a new disk. I don't have any new disks. A while ago I did switch out an old RN31400 for a new RN31400 because it got fried during a power surge. What next step should I take to diagnose/fix the problem?Solved17KViews0likes10CommentsReadynas 104 - Slow transfer speeds
Hi all Can someone please tell me if the transfer speeds i am seeing are normal. I am pretty sure that i use to see around 70Mb but now i am only seeing 10Mb, both directions. When i transfer files from my PC to NAS or vise versa i am seeing speeds of around 10Mb, everything is on a 1G LAN so i would expect to see greater speeds than 10Mb. My setup is PC - Windows 10 with 1G NIC and SSD TP Link 8port 1G switch TP Link ADSL router with 4x1G ports RN104 using SMB for file transfer all cat5e cabling throughout. My ADSL link out to the network is 10Mb, to me it looks like when i am transfering files on my LAN the transfer is going out on the internet and back again, is this possible. Any help would be greatly appreciated.Solved16KViews0likes14CommentsSMB vs NFS: browsing performance
Hi, I have a NAS with a lot of small files, which I need to search through often. I use a file manager called FAR Manager, but that doesn't really matter. I've enabled NFS client in my windows workstation, and mounted same Share using SMB and using NFS as two different drive letters. Then I did a file search using filename only on both. NFS returned results around 5 times faster than SMB. The actual transfer speed is pretty much the same, so that's not a problem. Question: is it possible to achieve same browsing/listing performance from SMB? Thanks.15KViews0likes3Comments