firefly_242 - are you using just one NIC, or are you using some form of link aggregation?  If you are using multiple NICs, can you give us some info on the configuration?

Also, despite Alein's assertion, mdgm-ntgr found some evidence of a disk issue with one of your disks.  The vendor tools have fairly high pass/fail thresholds (which IMO is mostly because they want to control their warranty costs).  Can you download the logs again, and look at the SMART stats?  They are in multiple logs, one convenient place is volume.log.  While you are there, you can also check OS partition fullness (look at /dev/md0 in the === df -h === section of the log).

You can also look at network_settings.log and check the packet statistics for TX and RX packets.

tried to reply several times, but my reply is not posted

looks like the reply was too long:( Let's try the short version.

use only 1 NIC. SMART stats all show Zero for all disks. /dev/md0  is only 17%. TX and RX look good. No errors reported

Your issue wasn't the post length.  There is a spam filter that sometimes traps legit posts, and it triggered on yours. I can release them if you like, though perhaps it would just make the thread a bit confusing.

---

firefly_242 wrote:

SMART stats all show Zero for all disks. /dev/md0  is only 17%. TX and RX look good. 

---

Ok, that rules out ethernet cabling, and a filling OS partition.  Disks look fine (I did check your quarantined posts, and saw the stats).  Although SMART isn't infallible, it seems unlikely that they are the problem.

One possibility is just insufficient memory.  A stock Pro has 1 GB, currently shipping OS-6 NAS have at least 2 GB.

It could also be failing hardware.  That could be bad memory, and I have seen a couple of cases where replacing the PSU solved similar freezes.  Those two components can be replaced (as can the CPU), but the rest of the chassis isn't repairable.

The logs might give some more clues - perhaps look in system.log and kernel.log and see if there are any entries related to OOM (out of memory) conditions.  Look also for any evidence that processes are crashing (exceptions for instance).

ok, got it:) makes no sense to release those replies as it will indeed overflow this thread.

Can't find any OOM in system.log and kernel.log.

However in kernel.log I see this last entry before I had to reboot:

May 19 17:43:38 nas-storage kernel: Fixing recursive fault but reboot is needed!

checked the logs from 1 May crash and can't find the same message when the system hang

Ok.  Do you have the stock 1 GB of RAM?

If so, a risk buy of more RAM might be a reasonable step.  It eliminates one possibility, and might help overall performance/stability too  4 GB total gives you the same amount of RAM as the RN500 series, so it should be enough..

This memory should work, and if you are in the US would cost about $30.   https://www.amazon.com/dp/B002N52ZO4

FWIW, I went with 2x4GB Patriot RAM in my pro-6 some years ago, but there weren't a lot of PCs that could use that memory, and at this point anything over 2GB/slot is scarce/expensive.  

Of course you could simply revert back to OS 4.2, though it is a fair amount of work, and you might discover that the reliability issues remain.

ok, will give the memory update a shot. Did a internet check and parts are not available in the Philippines. will have to sort them from the US. Will take a some time.

BTW: already tried reverting to OS4.2 after my first experienced theses freezes when I first update to OS6. Also on OS4..2 I have the sam behaviour now. So, decided to stick with OS6

Update: took awhile to get the memory delivered to the Philippines, but finally got it. Bought the recommended one in the thread.

Strange thing is that after the installation of the 2 moduels the storage did not start up anymore. Only get the "READYNAS" screen.

Tried to go in to the boot menu, but also this is not possible.

Removed them again and reinserted the original 1GB memory and system boots up without any issues

Strange that the recommended memory blocks the system from booting. Any idea why?

First, verify they didn't send you the wrong memory.  Make sure it is DDR2 PC2 6400.

Then, there is always the possibility that one of the sticks or one of the slots on your NAS are bad.  Try each of the new sticks individually.

BTW, all it takes is 5V for the unit to say "ReadyNAS", so that's no clue as to where the problem lies.

Hi,

correct memory modules received.

Already tried using 1 new module yesterday and the system did not boot. Assumed that the module is not compatible. Did not try the second module. My bad. Turns out that the first module I use is faulty:( The second one works. Thanks for the hint.

Currently using the old 1GB and 1 new 2GB module.

The unit does not use dual-channel memory, so there is no advantage to making sure both sticks are the same, in case you just want to get a refund on the bad one.

Thanks for this info. Much appreciated

Hi,

System has been pretty stable. As we went on holiday last week and nobody was at home I shutdown the storage.

When I started it again yesterday it froze 2 times after about 30 min uptime and a 3rd time after a few hours. After that I only got the READYNAS screen. I removed the newly added memory (2GB) and the system booted again. But it still froze a few hours later:(

It is currently resyncing.

Logs from 3GB and 1GB configuration are available if needed.

Regards,

Werner

After some research, I was able to catch some information, when NAS freezes.

Through serial port, I was able to monitor NAS even when it freezes.

As you may see btrfs-tran+ is consuming one core (thread) at 100%

So I google for it, and that is what you should be looking for

btrfs-transaction stuck and consuming 100% CPU

In general, it is a bug in btrfs, as I understand it.

what can freeze really fast NAS are:

-rsync backup (read write)

-iSCSI ( in general)

-NFS (v3 and v4) as datastore

-removing old snapshots

-creating snapshots in smart mode ( ~0:00 is the time when new Snaps. are created and deleted we have a lot of concurrent I/O)

-compressed shares, especially iSCSI 

-a huge amount of files,>1M

We should have possibilities to use different FS, not only BTRFS.

Both of my Pro BE's (same generation as your Pro Pioneer) have upgraded processors, so that could be why I never saw the problem.  Unfortunately, a CPU upgrade is a bit trickier than a simple RAM upgrade.  Core2 Duo E7500's can be had on eBay for around $3 these days, and that'll really up the throughput over the original Pentium E2160.

That upgrade does require the latest BIOS.  Check the forum to see if you have it and how to upgrade.  Or, stick to the Core2 E6600, which doesn't need it but is still a lot more CPU than stock.

Hi,

Experienced anotehr hang of my storage.
This time I was still able to login with putty via the second lan port.
top command shows the system is almost idle:
top - 08:33:56 up 3 days, 21:15,  2 users,  load average: 4.05, 4.03, 3.42
Tasks: 210 total,   1 running, 209 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.0 us,  0.3 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   1011636 total,   959504 used,    52132 free,     2184 buffers
KiB Swap:  1308156 total,    81356 used,  1226800 free.   508880 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 4396 admin     38  18 1333688  34644      0 S   0.7  3.4 155:29.06 utserver
12128 root      20   0   28772   2944   2340 R   0.3  0.3   0:00.05 top
    1 root      20   0  136720   4268   2968 S   0.0  0.4   0:05.78 systemd
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.37 kthreadd
    3 root      20   0       0      0      0 S   0.0  0.0   0:10.25 ksoftirqd/0
    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H
    7 root      20   0       0      0      0 S   0.0  0.0   0:42.66 rcu_sched
    8 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh
    9 root      rt   0       0      0      0 S   0.0  0.0   0:00.56 migration/0
   10 root      rt   0       0      0      0 S   0.0  0.0   0:00.70 watchdog/0

seems I am facing another issue that causes the system to hang.
Regards,
Werner

Hi, Still faceing system freezes fro mtime to time. Am on the latest FW (6.9.4).

Starting to suspect a HW issue for the errors I see in Kernel.log. But erros are not consistant. Last issue was on Oct 13 and I see this in the Kernel.log file before I rebooted:

"Oct 13 07:22:27 nas-storage kernel: alloc_fd: slot 3 not NULL!
Oct 13 07:22:27 nas-storage kernel: alloc_fd: slot 4 not NULL!
Oct 13 07:22:27 nas-storage kernel: general protection fault: 0000 [#1] SMP "

followed by some CPU data and:

"Oct 13 07:22:27 nas-storage kernel: Fixing recursive fault but reboot is needed!". 

However, other freezes show in Kernel.log:

"Sep 29 06:22:48 nas-storage kernel: eth1: hw csum failure"

and the same for eth0 on another occassion:

"Sep 19 06:12:44 nas-storage kernel: eth0: hw csum failure"

Confused with these contradicting mesages. Any  idea how I can find out what is causing this?

Thanks.

I suggest running the memory test from the boot menu.

Ran 5 passes of memory test. all passed

Perhaps try downgrading to 6.9.3 and see if that is more stable.

Hi,

issue is happeing since I upgrade to 6.9.2 from OS4.2. Also happens with 6.9.3 and all the released beta's.

Also tried reverting back to the latest stable OS4.2 (RAIDiator-x86-4.2.31), but issue also happens there. So, can only be a HW issue.

However, the alarms are not consistant. Maybe I just have to accept that the system is reaching it's end of life.

---

firefly_242 wrote:

Maybe I just have to accept that the system is reaching it's end of life.

 

---

Very possible, especially since it is happening on both OS 4.2 and OS 6.