The RN214s were purchased in April / May 2020 and the RN424 in April 2021
I went back in Italy for Xmas but family commitments kept me there until now, mid May.
While abroad, very occasionally, I logged on the NASs, and in February, I noticed that RN214b had gone offline; I asked a friend to go and check and she rebooted it (I instructed her to pull the plug, as it was unresponsive). I think I checked it again in April and it appeared to be “Online”, but it was Offline when I arrived back home.
This situation seems to be similar to the one described in
RN21400 Suddenly Goes Offline but is actually running
as all my NAS have a double NIC to allow bonding, but inreality I tried to implement the bonding but failed on the RN214s. I thought that my “basic” router would not support bonding and I purchased a GS32T, but although on the RN424 the bonding was successful, both the RN214s would go offline as soon as the second “bonded” NIC was connected. I planned to have a further look at this issue with a post on the forum, but I already had two posts open, so I waited a later time.
All NASs were left configured with double bonding in place, but eth1 was unconnected on the RN 214s (so both NICs were “in use and powered”) - (unfortunately): this was the situation for the last year/18 months. No apps installed on RN214b (Plex on 214a, use it once and pretty unnecessary for my use).
I followed the advices on that post above, but unfortunately I did not get to the “happy ending”: the RN21b, now connected using an unbonded single NIC (on eth1 now but there seems to be little difference between the two NICs), would boot up, stay online for a matter of minutes, then becomes unavailable.
The fan does not seem to respond to the software settings either: even if I set it to “Cool”, the rpm remain @<800. I tried to swap it for a similarly identical fan from a dead RN104, when I rebooted RN214b I saw 2785rpm, but five minutes later the data was unaccessible, and next reboot the fan was running <800rm again. The unit is currently off and “naked” (no side panels).
This is the situation thus far.
Any possibility that a FW update may fix any of the issues (which seem to be hardware issues, to my eyes) ?
Any further test I could do?
Further comments
The RN214a is currently using eth0. Is it advisable to switch to eth1, if that seems to be less temperature sensitive, or that is only the case when both NICs are in a bonded state and “in use”?
Is it advisable to keep the double bonding on the RN424, given that the speed advantage is minimal, or should I just use a single unbonded NIC, alternating eth0 and eth1 once a year or so?
IF the unit has suffered a terminal fault to both NICs – and has to be considered DEAD, then I really don’t know what to do, because NETGEAR ReadyNAS seems to have disappeared from the UK market: Six months ago, I could still find RN424s on Amazon.de, but that does not seems to be the case anymore; so the option of plugging the entire array in a new unit (214 or 424) doesn’t seem to be available to me anymore.
If I am correct, I can switch off the RN 214a, remove all disks (ordered & labelled), load all the disks from the faulty RN214b and power it up. The R214a should read that full array. That should allow me to transfer all the data on a WD10EFAX currently empty. The disks could be formatted and used somewhere else.
I can switch off the RN 214a, remove all disks (ordered & labelled), load all the disks from the faulty RN214b and power it up. The R214a should read that full array. That should allow me to transfer all the data on a WD10EFAX currently empty.
Correct. You can also migrate the disks to the RN424 (or in the other direction) - though the system will need to switch the OS from arm->x86 (or vice versa) when you do that.
“ Correct. You can also migrate the disks to the RN424 (or in the other direction) - though the system will need to switch the OS from arm->x86 (or vice versa) when you do that.”
I went for a simple array migration to the RN214a (which now calls itself RN214b, but using a different IP).
Unfortunately it showed the same problem as the previous “Unit b”. The file system came up but very slowly. RAIDair showed the unit online, but not the Admin & Browse icons for at least five minutes.
Then I instructed a full data (minus the snapshots) “Teracopy” over the WD10 target drive, but that did not start (because the target drive was too small by 76Gb), but I only realised that 2h later when I checked it, and by then the unit was frozen; I unplugged it and restarted, simply to see a CPU temperature of 71° and likewise extremely high temps for the drives. OUCH.
I let it cool down for 2 or 3h, then I managed to transfer 78Gb of data before it hung. This morning I tried to copy one folder, data transfer speeds were ~104Mb/sec but then it froze 10 seconds before the end. This evening, the file system was up for a matter of seconds before hourglassing; the unit hung, although the temps were lower than 30° all around (incidentally, I moved the unit to a more “exposed” position, removed the side cheeks and top panel to allow more air in; the drives were also removed and left on the desk to cool down and inserted just before rebooting).
Now I don’t know anymore what to think
Should I return the RN214a array to the “Unit A” and check if that is still functional?
Should I instead test the RN214a array in “Unit B” to see if that hardware is faulty as I assumed it was?
Should I presume that the 6.10.3 FW on the RN214b array has got corrupted somewhat, upgrade it to (say) 6.10.4 and see if an uncorrupted firmware can read the exhisting file system?
Should I try the RN214b array in the RN424, maybe some more robust hardware (also with a much bigger fan) could read the file system? But that would imply a firmware upgrade anyway (arm to x86_64) so basically also similar to the previous option + hardware advantage?
Thank to everybody in advance
p.s This is the content of diskinfo.log from the logs download taken before switching the array to the RN214a unit:
I went for a simple array migration to the RN214a (which now calls itself RN214b, but using a different IP).
Unfortunately it showed the same problem as the previous “Unit b”. The file system came up but very slowly. RAIDair showed the unit online, but not the Admin & Browse icons for at least five minutes.
So the disks in RN214b cause the same problem when migrated to RN214a.
I would next try the RN214a disks in RN214b, and confirm that the problem doesn't occur in RN214b with RN214a's disks.
I'd also take a look at the OS partition fullness (not that likely to be the issue, but easy to check). Look in volume.log, and scroll down to the df -h section. /dev/md0 is the OS partition.
While removing the sides may help with the CPU temperature, it may have the opposite effect on the drives because the air entering through the side doesn't go over the drives. Opening the door is typically a better approach.
But those temperatures, assuming a reasonable room temperature, indicate there is a whole lot of activity going on (like a scrub) or the fan is not working properly or is blocked. Whatever that activity is could be bogging down the unit. If you have SSH access, see what top says is running and if anything is using a huge amount of CPU.
“I would next try the RN214a disks in RN214b, and confirm that the problem doesn't occur in RN214b with RN214a's disks”
Did that. But Unit-b (I guess) failed to read the file system properly. RAIDair reported “Volume inactive”, it thinks that the disks were 100% full. On the admin page the disks all appeared red instead of blue.
I cannot remember how full it was, but my guess is ~70%, maybe 75%. You may remember my post “vertical expansion of the wrong Nas”, I expanded RN214b instead RN214a exactly because RN214a did not need to be expanded.
I switched Unit B from the dashboard – and it DID switch off (took 52seconds): it might have been the first time I did not need to “pull the plug”.
Thanks for the comment on the chassis side. What about the top cover?
Re the fan, I mentioned in the first post that I tried the fan from a dead 104, and it did not seem to be the problem; I wasn’t sure if the CONTROLLING of the fan was correct (changing the fan mode to Cool did not seem to have much of an effect, while changing to Balanced on the RN424 caused an immediate response, but that might have been because the 8Tb disks in the RN424 were actually warmer at that time).
On a different occasion, when I saw the high temperatures, the fan was running ~2700rpm. I am NOT saying that the controlling is correct, it may kick in too late, I simply think that there is something else in the reading of the file system which has gone wrong in “Unit-b”, which also just misread the file system of Unit-A.
Incidentally, the dashboard on the RN214b did not see to be 100% either: clicking the refresh button did not have any effect on temperatures and fan rpm, refreshing the page did not have any effect either, totally identical figures.
Let’s clarify something about my devices and their names
Unit Type Array Network name FW
A RN214 A RN214a 6.10.3
B RN21A B RN214b 6.10.3
C RN424 C RN424 6.10.4
This clarification is needed because, when I tested the (troublesome) Array B in Unit A, that one appeared on the dashboard as RN214b, so the name were now mis-aligned.
The situation as moment is as follows:
Unit A/Array A/RN214a It appears to be healthy, all data accessible.
Unit C/Array C/RN424: It appears to be healthy, all data accessible.
Unit B/Array B/RN214b: Array not loaded, NAS in “safe mode” (no disks)
I reloaded Unit B with Array B (original RN214b setup). No changes, it stays up for 10 minutes and then it hangs.
Unfortunately, no further progress has been made since then, but I still have one NAS immobilised (maybe faulty but we aren’t sure) and one array accessible but only for minutes, maybe damaged or maybe recoverable
.
Any further suggestions?
I though that maybe an OS reinstall on Unit B might be beneficial.
I might even have a spare HDD to use for a factory reset too, but then, wouldn’t loading Array B reinstate the OS on the array?
I though that maybe an OS reinstall on Unit B might be beneficial.
I might even have a spare HDD to use for a factory reset too, but then, wouldn’t loading Array B reinstate the OS on the array?
I think it will be less confusing if we call the Arrays X, Y, and Z (with X being originally installed in Unit A, Y being originally installed in Unit B, and Z being originally installed in Unit C).
An OS reinstall just reinstalls some of the OS from the flash image onto the disks. Similarly, a factory reset just does a complete install onto the disks (formatting them, etc).
If I recall the history correctly,
Array Y also has the same hang when it is installed in Unit A
Array X failed to mount when it was installed in Unit B.
So there appears are two problems here - one is the hang (which appears to be related to Array Y), and the other is Unit B hardware.
I would first use the spare disk in Unit B. Do a factory reset using the boot menu. Then do a minimal setup. If that doesn't hang or otherwise misbehave, then try booting the system with that disk in every bay (making sure you can access the volume, and that you don't have any hangs).
Then I would install Array Y in Unit A (powering down of course), and then attempt the OS reinstall while it is in Unit A. Then see if the hang is resolved. The idea here is that Unit B isn't fully trustworthy.
If the hang is not resolved, then you probably need to try a factory reset with Array Y in Unit A. That of course will lose all the data on the array. If you have no backup, then you could try RAID recovery software in a PC - expensive and not guaranteed to work.
If the hang is resolved, and you have no backup of Array Y, then you should make one at that point (while the array is installed on a system with known good hardware).
If all that works - no more hangs with Array Y in Unit A (either due to the OS reinstall or the factory reset) plus Unit B boots with the spare disk in every slot - then try putting Array Y back in Unit B. If Array Y doesn't mount in Unit B, then I would try swapping the power bricks for Units A and Units B, and see if the mount issue is power related.
Hello Forum, apologies for the delay, and thank you for the patience
Too long a story. Spent over two months copying the data which could be seen on Array B when loaded on Unit A. Some data was lost, (half dozen folders) but the bulk (9.6 TB) could be copied over. The snapshots, ~4TB, were lost: although the Windows switches were ticked on, neither the dashboard (which would freeze after ~20 seconds, nor Explorer or Total Commander (used to resolve some “long name” issues) could actually SEE any files: the snapshot folders seemed to be empty (there were two “dated folders” which then disappeared at some stage during the copying which took forever).
Unit B was tested with the test disk, swapped bays etc, and seemed flawless. Power bricks were ok too (I tested them before receiving the advice).
The “hang” on Unit B was eventually resolved (OS reinstall with Array Y on Unit B, a previous attempt to backdate the FW on Unit A was unsuccessful). Array Y is now back on Unit B, and seems perfectly operational on eth1 – streaming videos 24/7 to the TV (but I also had 4 VLC processes running videos on a loop on two PC simultaneously for a couple of days, and did not seem to suffer).
It seems to me that the issue was the Array, more than with Unit B itself .
The fan seems to keep HDD temps below 45°C on “Cool”, below 50°C on “Balanced” and ~52°C-53°C on“Quiet” (I presume it would aso respond to CPU temps, but Unit B does not seem to be stressed right now).
Now:
a) which sort of test shoud I run to ensure that Unit B is actually “performing as it should” ( I just switched to eth0 to see if I have issues with that NIC)
b) Array Y was (originally) a 4x4TB array which was vertically expanded to 3xWD80EFBX + the last 4TB; since the entire dataset has been backed up, it makes sense to me to expand the 4th HDD to 8TB, do whatever advised to have a SIMPLE RAID5 (a factory reset maybe) and start afresh without the md126/md127 two-grouping (could that have been responsible for the array corruption?).
c) the WD80EFZZ is not on the compatibilty disk for either the RN424 nor the RN214. Is anybody familiar with this drive yet? (128Mb cache and 5640 rpm..??) (the WD80EFBX seemed and to be “End of Life”, the WD80EFAX is nowhere in sight too.
a) which sort of test shoud I run to ensure that Unit B is actually “performing as it should” ( I just switched to eth0 to see if I have issues with that NIC)
I'd run the maintenance test (putting them on a schedule). Personally I run one test a month (cycling through them 3x a year).
b) Array Y was (originally) a 4x4TB array which was vertically expanded to 3xWD80EFBX + the last 4TB; since the entire dataset has been backed up, it makes sense to me to expand the 4th HDD to 8TB, do whatever advised to have a SIMPLE RAID5 (a factory reset maybe) and start afresh without the md126/md127 two-grouping (could that have been responsible for the array corruption?).
Those two RAID groups will last as long as the volume does. Upgrading the last disk won't change that.
But after the upgrade, you could destroy the volume, create a new one, and switch back to XRAID. Or alternatively do a factory default with all disks in place. That will result in a single RAID group (until you choose to expand again). Of course you will need to recreate shares, reinstall apps, and restore all the data.
c) the WD80EFZZ is not on the compatibilty disk for either the RN424 nor the RN214. Is anybody familiar with this drive yet? (128Mb cache and 5640 rpm..??) (the WD80EFBX seemed and to be “End of Life”, the WD80EFAX is nowhere in sight too.
Not surprised that it's not on the HCL. Netgear has always been very slow on updating it, and all indications are that they are abandoning the NAS products. So not much incentive for them to keep testing drives.
Ordered (and got) a Seagate Ironwolf ST8000VN004 (the 022 is end of life – same specs, 256Mb cache, a tad noisier, maybe).
Re the New Volume with 4x 8TB, without “grouping”.
The SM says that I can only destroy a SINGLE Volume if I am in Flex-RAID, but although I am in X-RAID, “Destroy” is not greyed out (?).. So supposedly I could:
destroy the volume & power off
swap the 4TB with the new 8TB & power on again
Create a new Volume
That should avoid a double syncing operation and save time.
Alternatively, I could do a factory reset and could I then inport a configuration back up from this unit, or would it have the md126/127 grouping? (if so, I could use the configuration from the other units and edit the name and network fixed settings)
But I am still uncomfortable, as we don’t really know what happened and why.
I wish to be reasonably confident that I can RELY on this piece of hardware before it goes out of Warranty.
I run an HDD test: it finished without highlighting any issues.
I run some transfer speed tests to highlight possible difference between eth0 & eth1, but I cannot see anything appreciable (within 2%).
“I'd run the maintenance test (putting them on a schedule). Personally I run one test a month (cycling through them 3x a year).”
I think you were referring to the maintenance schedules (scrub, defrag, balance). They should help maintain the disk in good health, but I was asking if there was something else I could do “stress” the hardware to highlight any weaknesses.
With regards to defragging, I was planning to enable the “Autodefrag” with the checkbox: I don’t have any iSCSI device ( that I know of ) and 90% of the data is video or images on store, once written down, it is simply read out.
There is another thing which has gone wrong: the email warning stopped working some time ago, and I cannot seem to get them to work again.
That uses a gmail addreess mailing a yahoo address, so all the server are filled in automatically ( but even filling them myself in the advanced does not change the result): I get error 500.801.0001 .
Re the New Volume with 4x 8TB, without “grouping”.
The SM says that I can only destroy a SINGLE Volume if I am in Flex-RAID, but although I am in X-RAID, “Destroy” is not greyed out (?).. So supposedly I could:
destroy the volume & power off
swap the 4TB with the new 8TB & power on again
Create a new Volume
That should avoid a double syncing operation and save time.
Alternatively, I could do a factory reset and could I then inport a configuration back up from this unit, or would it have the md126/127 grouping? (if so, I could use the configuration from the other units and edit the name and network fixed settings)
No matter how you do it, if you create a volume with 4x8TB disks installed you will end up with only md127. Reapplying the configuration file won't change that. The various raid groups correspond to partitions on the disks, and simply applying a configuration file doesn't reformat/repartition the disks.
As far as double-syncing goes - you can destroy a volume while syncing is in progress. So that is really not a concern.
You should be able to destroy the volume in either XRAID or FlexRAID - though honestly I've only destroyed them in FlexRAID. Of course if you are using XRAID you only have one volume to destroy. If you are in FlexRAID and have multiple volumes, you can certainly destroy them all (one at a time).
Uninstall all your apps before saving the config file, and reinstall them after you reapply the file.
But I am still uncomfortable, as we don’t really know what happened and why.
I wish to be reasonably confident that I can RELY on this piece of hardware before it goes out of Warranty.
I run an HDD test: it finished without highlighting any issues.
FWIW, I'm not seeing a whole lot of evidence that two RAID groups makes the system a lot more fragile. My main NAS and one of my backup NAS have two RAID groups, and I've never lost a volume on either one.
But I agree that we really don't know what happened here.
IMO, the best way to minimize any discomfort is to implement a solid backup plan, so your data is safe even if the NAS fails.
I think you were referring to the maintenance schedules (scrub, defrag, balance). They should help maintain the disk in good health, but I was asking if there was something else I could do “stress” the hardware to highlight any weaknesses.
Scrub and Disk Test both do a good job of exercising the disks. Stressing the NICs could be done with a transfer test - there are several free programs that will benchmark NAS performance by creating/transfering files over and over. If you just want to test the network, you could install iperf on the NAS and a PC - then use that to test the network performance. Plex transcoding would be a reasonable way to test the CPU, but could be a bit trickier to set up.
