Readynas 104 drops out when copying to it

Yes, data will have to be wiped and copied back. Might as well do a factory default, since deleting the data volume will also remove any apps (they are stored in /data/.apps/).

Hi Chirpa,

Thanks for your prompt advise.
One thing more, if may i, what is considered more stable and probably with a better performance x-raid or flex-raid ?
Not talking for expansion things. Only Raid-5.

Thanks
Alex

What a complete balls up! How did the 104 get the green light for release, was there no testing at all?

You're asking those who were unfortunate enough to buy one of these to copy off around 7TB of data (to where, but if you do have it lying around! that's 4 and a half days gone) then factory reset and rebuild the array (that's 36 hours), then copy the data back again (another 4 and a half days). Great work to the d-head that wrote the shitty btrfs... sincerely hope he's been fired.

I'll never buy a Netgear product again, worst product purchase experience EVER.

alexk2013 wrote:
... what is considered more stable and probably with a better performance x-raid or flex-raid ? ...

don't think it matters. Apart from the expansion scripts, the two are basically the same - using software RAID combined with the btrfs file system.

Hello all,

please add me to the list! :(

I came across exact the same problems in the last 4 weeks!! :evil:

I am a longterm user of ReadyNASs and I was always pretty happy with those. Started with the old 600s....Duo....NV+.....Ultra4....104...314.
So my productive rig was the Ultra4 with 4x3TB. Which was at 99% full.
So I bought 4x4TB and added them step by step. After waiting for the expansion to finish I realized that I used an old 500GB disc back in the old days to set it up. So the NAS could not expand to full capacity! :(

So I thought, time for a new rig. So I bought a 104.....and before setting it up completey I exchanged it with a 314.
So now I put the "old" 4x3TB in the 104 than copied all files off the Ultra4 to the 104. Than added the 4x4TB to the 314 and again copied all files from the 104 to the 314. As this took more than 2 weeks as I was always having trouble with copying!....dropped connections....could not write....all that kind of sh..t.
I finally had all files on the new NAS yesterday! :) .....and got rid of the 104. so now I have the Ultra4 and the 314......

And now you guys tell me.....with all the problems I have/had I will have to used the next firmware AND do a Factory Reset !! :twisted:
So where exactly should I now "safe" the ~8TB of Data ???

And as others said: All the time wasted! To find out, that you have to do it again! :cry:

Well it is good news, that finally you found the root cause...and it is supposed to be fixed in the next firmware, but the consequence to do factory defaults all the time....is really.....annoying!

The CHEAPEST solution is to buy another 2x4TB disks and use them to copy all data to.....but that is another 350 Euros least! That is almost the PRICE of the 314 !!!!
Piece of sh...t.

So....I really hope in the future....this won't happen too often.
Because right now....I really can't find any reason to buy another ReadyNAS ever again!

Cheers
Hossa

I might as well share my "story" here as well. I have the same issues as described here with 2 104's and 314. At first I thought that I was just pushing too much to the 104's which is why I purchased the 314. That doesn't appear to be the case however since I have the same issue with all 3 devices.

My biggest issues come with copying large files (several GB) over NFS or AFP (everything that I use is either Mac or UNIX so I do not use SMB at all). I've also caused the 104/314's to hang when performing rsync backups via SSH (although this doesn't occur as frequently and isn't nearly as reproducible).

My setup is as follows;

- 3 ReadyNAS devices, 2 104's and 1 314
- All ReadyNAS devices have 4 Seagate ST4000DM000 4TB drives
- I use a single X-RAID volume on each device (RAID 5, ~10.5TB formatted space)
- Used disk space is between ~1.7TB and 3.1TB on each ReadyNAS (due to the disconnections, I can't seem to get any data on these)
- I only have NFS, HTTP, HTTPS, & SSH running on one 104 and the 314. The other 104 has AFP running in addition to the other protocols.
- Each device has a single NFS share (the 104 that has AFP uses both NFS and AFP for this share)
- I use adaptive load balancing NIC bonding on all 3 devices (although, I can and have reproduced the disconnects without NIC bonding enabled)
- All 3 devices connect to a Cisco 3750 gigabit switch (I can also reproduce the issue using a direct connection to a server via a crossover cable)
- My client devices also connect to the Cisco 3750 (48 port) switch. Wireless clients connect via an Apple AP that is connected to the 3750 as well.
- Clients range from Apple laptops (only wireless clients), to Mac Mini Servers, to dedicated UNIX (Linux and Solaris) servers, to VMware ESXi servers (UNIX clients).
- I can reproduce the disconnections from wired and wireless clients although, it's much more prevalent with wired clients.
- ReadyNAS devices are used primarily for backups. I run my backups in a serial fashion (ie: no 2 devices ever perform a backup task at one time).
- If more than one device runs a backup task at the same time, the ReadyNAS will lockup about 95% of the time.
- If only 1 device is executing a backup at a time, I only see lockups about 80% of the time.
- Backups run either via rsync over SSH (remote jobs) or direct file copies over NFS.
- The rsync jobs transfer only small files over the internet and are far more reliable than the NFS jobs. The NFS jobs transfer mainly large files (up to 800GB/file).

I have been fighting these disconnections since May of this year and have tried a great deal of configurations. I even rewrote my backup tasks to assure that only one backup was running at a time. This improved things but not to an acceptable (ie; usable) degree. I did set "vm.swappiness = 60" in /etc/sysctl.conf (and rebooted) which did help quite a bit (instead of the device locking up 100% of the time, that number is now closer to 80%).

I was able to capture the output of "top" when my 314 died last night, here is what it looked like;

top - 10:48:04 up 1 day,  8:33,  1 user,  load average: 6.95, 5.90, 3.81
Tasks: 149 total,   4 running, 145 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us, 99.4 sy,  0.0 ni,  0.2 id,  0.2 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem:   2039220 total,  2009300 used,    29920 free,      216 buffers
KiB Swap:  1047932 total,    57252 used,   990680 free,  1742152 cached
Write failed: Broken pipe
curt@tatiana:~$
  491 root      20   0     0    0    0 R 111.9  0.0  38:37.80 kswapd0                                                              
    2 root      20   0     0    0    0 R  98.1  0.0  35:41.68 kthreadd                                                             
26706 root      19  -1  4176  484  484 R  98.1  0.0  10:13.47 sh                                                                   
 2030 root      19  -1  488m 2788 2788 S  94.7  0.1  34:28.26 readynasd
18695 curt      20   0 28484  716  632 R  57.8  0.0  13:27.02 top                                                                  
 1007 root      20   0     0    0    0 S   0.2  0.0   0:02.51 md1_raid6
 1969 root      20   0     0    0    0 S   0.2  0.0   2:44.90 flush-btrfs-2
 2155 root      20   0     0    0    0 S   0.2  0.0  35:57.79 nfsd
    1 root      20   0 45300 1168 1168 S   0.0  0.1   0:17.19 systemd
    3 root      20   0     0    0    0 S   0.0  0.0   0:01.44 ksoftirqd/0
    6 root      rt   0     0    0    0 S   0.0  0.0   0:20.29 migration/0
    7 root      rt   0     0    0    0 S   0.0  0.0   0:01.16 watchdog/0
    8 root      rt   0     0    0    0 S   0.0  0.0   0:12.88 migration/1
   10 root      20   0     0    0    0 S   0.0  0.0   0:00.77 ksoftirqd/1
   12 root      rt   0     0    0    0 S   0.0  0.0   0:00.88 watchdog/1
   13 root      rt   0     0    0    0 S   0.0  0.0   0:20.89 migration/2
   14 root      20   0     0    0    0 S   0.0  0.0  13:31.54 kworker/2:0
   15 root      20   0     0    0    0 S   0.0  0.0   0:01.21 ksoftirqd/2
 2155 root      20   0     0    0    0 D   8.0  0.0  11:27.07 nfsd
 2154 root      20   0     0    0    0 S   7.6  0.0  11:51.29 nfsd
 2152 root      20   0     0    0    0 D   6.6  0.0  11:32.86 nfsd
 2153 root      20   0     0    0    0 S   6.6  0.0  11:29.58 nfsd
 2159 root      20   0     0    0    0 D   6.6  0.0  11:32.95 nfsd
 2158 root      20   0     0    0    0 S   5.3  0.0  11:30.62 nfsd
 2156 root      20   0     0    0    0 S   4.0  0.0  11:21.16 nfsd
 2157 root      20   0     0    0    0 S   3.3  0.0  11:39.94 nfsd

In this case the load average was relatively low, I've seen it as high as 30 in the past. As you'd expect, the load average is generally higher on the 104's than the 314.

I have dug through everything in /var/log and have yet to find anything useful. On the same token, I have not attempted to add any additional logging.

I'm really hoping that 6.1.5 takes care of these disconnects. I purchased the ReadyNAS devices as replacements for Solaris/FreeBSD file servers with the intent on lowering my administrative overhead. Up to this point, these devices have been an even bigger headache than maintaining dedicated file servers. :(

Issues with 3 Readynas NV2 v2 ( twice as once they fixed the firmware they release a beta with the original bug) and now 3 * RN104

Phone call today from support to say that the new firmware should fix it but non-commital on release date
"could be days maybe this year or early next year". Then went on to say that only as a last resort do Netgear advise factory reset.

To be kind the guy is only doing his job but Netgear seem to have a pattern developing that to keep up with the market they release new products with only cursory testing and actually do not have any idea of what they are releasing or have any units on hand to validate/replicate any customer issues and have a basic difficulty in appreciating what the customer issues are Then their usual response eventually is new firmware, factory rest.

As everyone states you put the data on then where do you put it when you have to to factory reset

enough is enough synology here I come

Got the problem too. Hopefully I got just enough space to get back on my feets so I'll do it the clean way hoping the update will fix everything.
Do you have the changelog for us to see ?

I hate Netgear way to handle the factory reset. I'd appreciate to be able to mess around with SSH and just clean things up in a minute to start clean. A simple rsync script with --delete could do the trick most of the time no ?
Netgear would say RAID is never as good as a backup and that we should have at least two ReadyNAS. With that setup, we should be able to wipe without problem, having only one copy running for 24H. They're right about backup, but doesn't justify the downtime (up to two days to rebuild an empty array ? and what if the files are mirrored via xDSL or any weak site to site connection, we just wait a few weeks for things to sync ? ).


For those who don't want to wipe things out, BTRFS is easily resizable if my memory doesn't fail me.

so you can try this :
1°) Shrink the volume
2°) create and mount the new volume
3°) copy data from the old volume to the new one (you would want to preserve permissions, rsync is a good bet to resume a failing transfer)
4°) delete the copied data from the old volume and repeat step 1 to 3 till all data is copied (for those who don't have enough space to do it in one step)
5°) edit the /etc/fstab to mount the new volume instead of the old one at boot
6°) unmount the old volume
7°) delete the old volume
8°) reboot to check if everything boots up (Netgear ought to have seperated system from data, so should reboot with or without data mounted) or just remount the new volume for it to get to the right mount point.
If everything was done right, the system shouldn't see any difference, your share permissions should work fine.

I never tested that, I don't know much about readynas arch. But strictly linux speaking, this should work.
POTENTIALLY UNSAFE, NOT SUPPORTED BY NETGEAR, NOT TESTED.

There is also a procedure to do a restore without loosing data (http://www.readynas.com/forum/viewtopic.php?p=196365#p196365) which gives something like that.
umount Data (or remount RO)
erase /
reboot
use paperclip reset option to reinstall OS.


You can try those methods with no warranty but I strongly advise to do it the Netgear way. I personally won't try any of the two methods.
Hope the firmware will fix everything. (still waiting for some core function in the web interface too, like disk spindown, CPU/RAM/network/diskSpeed/DiskIO in performance tab, management at folder level (not share)...)

I can't believe they are quoting MAYBE next year for the update that will MAYBE fix the issue. When was the 104 released? it's like selling a car that can only use one tank of gas before it stops working, and then asking people to wait 6 months for the fix! I can't believe the way Netgear are treating their consumers.

I can highly recommend the QNAP TS-420... IT WORKS! for a start, and you can tell that it has clearly had way more time spent in development. The user interface is miles better too.

Just want to share yet another story.

Have a RN104 and 4xSeagate NAS 4TB.
Problems with NAS as soon as a few TB is copied to it, drops but responds to Ping. You all know the details...
Had a support-case with a lot of testing before they wanted replace my NAS a few weeks ago.
Received my replacement-NAS last week, same problems as with the old one...

Sent in a new support-request a few minutes ago and I’m thrilled to see what the response will be.

(Support case 22185567 and 22360759)