NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Performance/Admin Page Access - Does available disk space affect access to the ReadyNas
Hi,
I have a ReadyNAS NV+ and it has been running well for a while. A while back, I got a warning about the fan failing so I took the NAS out of commission for a while and got a replacement fan. I also got warnings about increasing bad sectors on one of the drives so I replaced it. I use the NAS as intermediate storage for my acronis images taken from my servers. I can't remember at what point, but my jobs began to take way longer to complete than they previously. I think it was after I replaced the drive which a WD10EFRX - WD Red 1TB NAS Hard Disk Drive. My backups literally take 4 times as long to complete. I replaced the 2nd drive with an identical WD10EFRX - WD Red 1TB NAS Hard Disk Drive drive and it still slower than it was previously. Unfortunately, I can't find the original drives that I had installed in the unit when it was initially provisioned. Both of the disks are healthy according to the NAS, but performance is still slow. I updated the firmware on the NAS. There is nothing in the logs apart from the occasional volume running out of space, which is normal in my situation. The NAS is connected to a 1Gb/s full duplex port. At one point I connected the NAS directly to the same switch that the servers are connected, however I saw no speed difference. There are 2 drives in a Raid 1 configuration.
Any assistance would be greatly appreciated.
Thanks in advance.
Are you using jumbo frames on your network?
It is a bit odd that you can't change the MTU. Perhaps try turning jumbo frames off, and do another test.
25 Replies
Replies have been turned off for this discussion
Hi DaneA.
It was hard to just mark one as the accepted solution, but it was a combination of suggestions that he made which got me the result I was looking for. A combination of checking my speed along the links, plus the block size and performing a factory reset. Also it included disabling journaling on the volume plus disabling jumbo frames.
Thanks a lot for all your help.
Hopefully it will last me a while. LOL.
Hi StephenB,
Turning off jumbo frames and switching the MTU to 1500 seemed to do the trick. The backup now takes significantly shorter than it used to. Performance is 85% back to the way it was when we first got the device. I can't remember if I had jumbo frames on when I initially got the device. Thank you both so much for your help!!!
Hi gt3,
I'm glad to know that StephenB's recommendation has helped resolved your concern. :) With regard to this, I encourage you to mark the appropriate reply as the “Accepted Solution” so others can be confident in benefiting from the solution. The NETGEAR Community looks forward to hearing from you and being a helpful resource in the future!
Cheers,DaneA
NETGEAR Community Team
Hi StephenB,
I disabled jumbo frames on the NAS and I was able to set the MTU. I reset it to 1500. I ran NAStester this morning and I got this:
NAS performance tester 1.7 http://www.808.dk/?nastester
Running warmup...
Running a 400MB file write on \\nas\backup 5 times...
Iteration 1: 14.21 MB/sec
Iteration 2: 21.00 MB/sec
Iteration 3: 23.10 MB/sec
Iteration 4: 23.13 MB/sec
Iteration 5: 22.86 MB/sec
-----------------------------
Average (W): 20.86 MB/sec
-----------------------------
Running a 400MB file read on \\nas\backup 5 times...
Iteration 1: 18.78 MB/sec
Iteration 2: 19.63 MB/sec
Iteration 3: 19.35 MB/sec
Iteration 4: 18.42 MB/sec
Iteration 5: 19.59 MB/sec
-----------------------------
Average (R): 19.15 MB/sec
-----------------------------This is the highest I have seen it so far. The real test will be when my full backups run on Saturday. I will post bright and early Monday morning with the results.
Thanks again.
[X] Disable full data journaling
[X] Disable journaling
[X] Optimize for OS X
[X] Enable fast CIFS writes
[ ] Enable fast USB disk writes.Above are the options checked on the performance page. Disable full data journaling is checked and grayed out.
On the network page "Speed/Duplex" is grayed out and set to autonegotiation. The status is "Online / 1000 Mbit / Full-Duplex." The MTU is 7936 and is grayed out. The "Enable Jumbo Frames" option box is checked.
Are you using jumbo frames on your network?
It is a bit odd that you can't change the MTU. Perhaps try turning jumbo frames off, and do another test.
Hi StephenB.
The "Disable Journaling" checkbox was cheched before the backup ran. "Optimize for OSX" is checked, although when I unchecked it before the factory reset, I noticed that performance dropped with similar speeds while the fiber connection was 100Mbps. I checked it after and performanced picked back up.
Hi,
Sorry for the delayed response, but here is the latest. I copied data from the NAS that I wanted to keep, then performed a factory reset. The factory reset took around 4 hours to fully initialize the drives. (2 X 1TB.) The following are from the logs:
Disk /dev/hde doesn't contain a valid partition table
Disk /dev/hdc: 999.9 GB, 999991611392 bytes
255 heads, 63 sectors/track, 121575 cylinders, total 1953108616 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/hdc1 32 4096031 2048000 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/hdc2 4096032 4608031 256000 82 Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/hdc3 4608032 1953092263 974242116 5 Extended
/dev/hdc5 4608040 1953092263 974242112 8e Linux LVM
Disk /dev/hde: 999.9 GB, 999991611392 bytes
255 heads, 63 sectors/track, 121575 cylinders, total 1953108616 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000
===== dumpe2fs /dev/c/c =====
dumpe2fs 1.40.11 (17-June-2008)
Filesystem volume name: c
Last mounted on: <not available>
Filesystem UUID: 689eab2f-f32b-493e-9513-ad422fc6c899
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 30310400
Block count: 60561408
Reserved block count: 0
Free blocks: 60051222
Free inodes: 30310384
First block: 0
Block size: 16384 ********
Fragment size: 16384 ********
Reserved GDT blocks: 127
Blocks per group: 65528
Fragments per group: 65528
Inodes per group: 32768
Inode blocks per group: 512
Filesystem created: Fri Sep 9 06:07:12 2016
Last mount time: Fri Sep 9 06:14:32 2016
Last write time: Fri Sep 9 06:14:32 2016
Mount count: 3
Maximum mount count: -1
Last checked: Fri Sep 9 06:07:12 2016
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 8a17c6bb-817d-442a-bba8-031a38365558
Journal backup: inode blocks
Journal size: 512M
NAS performance tester 1.7 http://www.808.dk/?nastester
Running warmup...
Running a 400MB file write on \\nas\backup 5 times...
Iteration 1: 7.59 MB/sec
Iteration 2: 17.91 MB/sec
Iteration 3: 18.36 MB/sec
Iteration 4: 18.17 MB/sec
Iteration 5: 18.17 MB/sec
-----------------------------
Average (W): 16.04 MB/sec
-----------------------------
Running a 400MB file read on \\nas\backup 5 times...
Iteration 1: 17.79 MB/sec
Iteration 2: 19.62 MB/sec
Iteration 3: 19.51 MB/sec
Iteration 4: 19.06 MB/sec
Iteration 5: 27.68 MB/sec
-----------------------------
Average (R): 20.73 MB/sec
-----------------------------
The surprising this is after I formatted, the backups took longer than it did the previous weeks. I verified that all links between the NAS and the server are 1Gbps. The NAS itself has autonegotiated the connection speed to 1000Mbit / Full Duplex according to the dashboard. The switch has also reported a 1Gbps link. There are 3 switches in the connection; the switch that the NAS is connected to, a stack of 4 switches connected via a backplane and another switch connecting the servers to the stack.
I'm not sure why it would be slower this week than previous weeks though.
Any ideas?
Thanks.Did you disable journaling after the reset?
Hi StephenB,
I'll start getting my stuff off the NAS tomorrow and early Friday morning after my incremental jobs run. I normally clear it out on a friday, but I will have to do it a bit earlier so that I can do the factory reset. I really appreciate the help from you and BrianL. I have been facing this problem for a while now and only recently decided to post about it. I am really impressed that both of you came swiftly with suggestions. I have no problem performing the reset and I can always delay the jobs until the reset has been performed and the drives have been fully initialized.
Once again, thanks so much for your help. I will keep you posted.
===== dumpe2fs /dev/c/c ===== dumpe2fs 1.40.11 (17-June-2008) Filesystem volume name: c Last mounted on: <not available> Filesystem UUID: e4456484-0503-4c24-81a8-39ecdaf52923 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype sparse_super large_file Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 30310400 Block count: 60561408 Reserved block count: 0 Free blocks: 32902557 Free inodes: 30308588 First block: 0 Block size: 16384 ******** Fragment size: 16384 ******** Reserved GDT blocks: 127 Blocks per group: 65528 Fragments per group: 65528 Inodes per group: 32768 Inode blocks per group: 256 Filesystem created: Thu Jan 20 16:00:26 2011 Last mount time: Tue Sep 6 13:25:01 2016 Last write time: Tue Sep 6 15:15:03 2016 Mount count: 5 Maximum mount count: -1 Last checked: Mon Nov 30 08:14:16 2015 Check interval: 0 (<none>) Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode: 8 Default directory hash: tea Directory Hash Seed: aa818a31-d661-43ed-a6ac-44aac4a2485b Journal backup: inode blocks Journal size: 512M
Looks like my block size is 14384.
Disk /dev/hde doesn't contain a valid partition table Disk /dev/hdc: 999.9 GB, 999991611392 bytes 255 heads, 63 sectors/track, 121575 cylinders, total 1953108616 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/hdc1 2 4096001 2048000 83 Linux Partition 1 does not end on cylinder boundary. /dev/hdc2 4096002 4608001 256000 82 Linux swap / Solaris Partition 2 does not end on cylinder boundary. /dev/hdc3 4608002 1953092233 974242116 5 Extended /dev/hdc5 4608003 1953092233 974242115+ 8e Linux LVM Disk /dev/hde: 999.9 GB, 999991611392 bytes 255 heads, 63 sectors/track, 121575 cylinders, total 1953108616 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0x00000000
Does this look OK to you?
Thanks.
The block size is fine. But since the starting sectors aren't divisible by 8 (e.g, 2, 4096002) you don't have 4K sector alignment. That likely is impacting performance somewhat.
A reset would probably help, but of course you need to balance the potential gain against the time it takes.
Any way to SSH into it so I can check the block size?
gt3 wrote:
Any way to SSH into it so I can check the block size?
Actually you can get it from the logs (download the log zip)
There's the block size, and also 4K sector alignment.
-Block size is shown in volume.log. It should be 16384.
-4K alignment is a bit indirect - you look in partition.log and examinine all the starting sectors. If they are all divisible by 8, then you have 4 K alignment.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
