OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!

With no help from anyone, I had to figure this out on my own.

Recovered data by extracting files from the OS 6.1.4 btrfs pool of the data partition onto a mounted nfs share of a separate remote NAS.
Reformatted ReadyNAS back to 4.2.24.

sgirard wrote:
Hi everyone, I just upgraded my ReadyNas Pro 6 to OS6 and loving it except one major thing. I'm finding that the system is constantly crashing. The only way that I can recover is reboot the machine until the next crash. Unfortunately, I haven't figured out what is the root cause yet. Do you any of you guys have any suggestion where I can look? Thanks S

Are you running any addons or software packages that generate a significant amount of disk I/O? If you copy a large amount of files to the device, will it at intervals freeze the copy?

I've finally figured out what was causing my Ultra6 to constantly freeze. A huge thank you to ACTIS, who volunteered a device to test some theories. It turns out that it was very hard to reproduce on his system, since that device was equipped with faster disks (7200v5400 rpm), a whopping 8GB of ram and a proper dual core CPU (not an Atom).

The problems on the Ultra 6 turn out to be the following:

• BTRFS and Atom processors do not really play well together. It can run on an atom obviously, but the Atom isn't well suited to handle the amount of calculations BTRFS demands.


• The 1GB of RAM. Upgrading to 4GB made a massive difference in general load on the system, but still did not resolve the I/O wait spiking to near locking point.


• Snapshots. Snapshots are an incredible pain in the behind. Even with the creation of new snapshots disabled, btrfs was constantly checking against the last snapshot on a subvolume, causing significant load when multiple threads are simultaneously writing to the device.

After deleting the snapshots, device load peaked at 7 when downloading with 40 simultaneous threads, a par2 repair and an unrar, while Sickbeard and Couchpotato were moving files around. As an added bonus, after all the snapshots were gone, the admin UI was about 50 times faster when modifying a share or access to a share. Permission changes were suddenly done in a few seconds instead of several minutes (and in some cases, a frozen device).

I'm still seeing some performance fluctuations, but the device is stable, doesn't crash when looking at it funny and most importantly: my girlfriend no longer nags me daily about missing her series.

Again a big thank you to ACTIS for volunteering a device so I could test this. You're awesome.

I seem to be going through the same level of learning on a fully supported 3220.

viewtopic.php?f=21&t=73788

Default for OS6 is to enable the snapshots on a newly created share, so I had 8 shares full of snapshots. System performance on a 4 thread i3 with 4G of RAM is in the dirt. I am in the process of removing snapshots to see if it salvages the system.

MueR wrote:

I've finally figured out what was causing my Ultra6 to constantly freeze. A huge thank you to ACTIS, who volunteered a device to test some theories. It turns out that it was very hard to reproduce on his system, since that device was equipped with faster disks (7200v5400 rpm), a whopping 8GB of ram and a proper dual core CPU (not an Atom). The problems on the Ultra 6 turn out to be the following: BTRFS and Atom processors do not really play well together. It can run on an atom obviously, but the Atom isn't well suited to handle the amount of calculations BTRFS demands. The 1GB of RAM. Upgrading to 4GB made a massive difference in general load on the system, but still did not resolve the I/O wait spiking to near locking point. Snapshots. Snapshots are an incredible pain in the behind. Even with the creation of new snapshots disabled, btrfs was constantly checking against the last snapshot on a subvolume, causing significant load when multiple threads are simultaneously writing to the device. After deleting the snapshots, device load peaked at 7 when downloading with 40 simultaneous threads, a par2 repair and an unrar, while Sickbeard and Couchpotato were moving files around. As an added bonus, after all the snapshots were gone, the admin UI was about 50 times faster when modifying a share or access to a share. Permission changes were suddenly done in a few seconds instead of several minutes (and in some cases, a frozen device). I'm still seeing some performance fluctuations, but the device is stable, doesn't crash when looking at it funny and most importantly: my girlfriend no longer nags me daily about missing her series. Again a big thank you to ACTIS for volunteering a device so I could test this. You're awesome.

MueR, thank you for writing this!
I'm experiencing somewhat the same behaviour on my Ultra 6 on OS 6.1.4 as you describe, so I'm about to disable snapshotting too. I have good daily backups, so I don't need the snapshots anyway.

One question: which modules did you use to upgrade the RAM to 4 GB on your Ultra 6? I've been reading so much on these forums about unsupported memory & possible data corruption that I've not yet taken the plunge to upgrade memory on mine, but I definitely want to!

BR,
Sven

I seem to be having similar issues on my Pro 6, ever since 6.1.4 came out the snapshotting is causing major load. I looked yesterday and i was at 10.4 load average.

Netgear likely doesn't read this, but if you are thinking up upgrading, stay with 6.1.1. 6.1.4 is pure garbage.

sventunus wrote:
MueR, thank you for writing this! I'm experiencing somewhat the same behaviour on my Ultra 6 on OS 6.1.4 as you describe, so I'm about to disable snapshotting too. I have good daily backups, so I don't need the snapshots anyway.

Be sure to delete your snapshots too! Snapshotting was disabled for over a month on my device, but the performance only increased when I had removed them.

One question: which modules did you use to upgrade the RAM to 4 GB on your Ultra 6? I've been reading so much on these forums about unsupported memory & possible data corruption that I've not yet taken the plunge to upgrade memory on mine, but I definitely want to!

I used a 2x2GB kit by Crucial, CT2KIT25664AA800.

Superb MueR, thanks!
----
*edit*: just ordered a 4GB set through Crucial, looking forward! :)

A good read for anyone running OS6/btrfs

http://www.sacrideo.us/btrfs-and-performance-troubles/

A REALLY good read if you run VMs. Netgear/Jedis, any of this stuff being looked at/worked on? A checkbox for a share that disables CoW options completely may go a long way. I see relatime is in there by default, but this still causes massive fragmentation on a VM file.

part of my 'mount' output:

/dev/md127 on /run/nfs4/data/dbs type btrfs (rw,relatime,space_cache)
/dev/md127 on /run/nfs4/data/logs type btrfs (rw,relatime,space_cache)
/dev/md127 on /run/nfs4/data/Public type btrfs (rw,relatime,space_cache)
/dev/md127 on /run/nfs4/data/vm2 type btrfs (rw,relatime,space_cache)

More digging gives a fun command called 'filefrag <filename>"

# filefrag dwin5.img
dwin5.img: 118655 extents found

This is a file on a share created for VMs. The file has existed there for about 3 weeks. It is a live machine. All snapshots are deleted, and continuous protection is turned off now.

Is 118655 extents to manage high? That is just one file :)

btw, just running filefrag causes the machine to go into IO wait at 27 to 38

Another VM file on the share:

filefrag dwin13.img
dwin13.img: 204276 extents found