NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
AMRivlin
Mar 20, 2013Apprentice
OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
Update: It is now unofficially possible using NTGR images to update legacy hardware to os6.X See Post #3, for directions to install 6.2.1 on x86 Ultra and Pro Models. (ARM NOT SUPPORTED by this OS) ...
- Jan 21, 2016
mdgm and I have decided that its time to lock this thread. So please do post any new OS6 on Legacy issues on their own threads.
MueR
Oct 28, 2013Aspirant
Well, that worked to a point... I'm now 100% sure it's the file system that's causing issues.
This is a copy from a game folder in my steam library to the NAS. It is just shy of 6GB in size and contains a large number of small files, as well as a few large ones. I had top open in a putty window while copying.

Every section marked in red, the BTRFS processes were dominating in top. Not just the transaction process, also a flush process, the various endio processes and the md127 process. Once they started floating to the surface, copying would grind to a halt (either below 30KB/s or even complete stops). At those points, I/O wait would also reach 75% on some of the cores. As soon as these processes would terminate (or sleep, whatever), copy would resume and IO wait would go to 2 or 3%, which is normalish.
As I am writing this, I've also restarted my sabnzbd and wait states are below 2%, load on the system is below 3. That is, until btrfs rears it's ugly head again, at which point wait spikes up again. I do not yet dare to re-allow both post-processing (par2, unrar) and downloading at the same time, since the crippled filesystem simply can't cope, where the ext system in OS4 had no trouble at all.
Netgear, this has got to go. BTRFS is not production ready. Heck, you've got a bloody release candidate on these devices (0.20-rc1, btrfs --version for those interested). This system is a disaster. In the time it took me to write four lines, load has spiked up from 2 to 7, simply because ONE process is writing to disk and btrfs can't keep up. The filesystem is using over 7GB for meta data alone, and every time you do something on the device, it increases. Not only that, but it has a scheduled time of locking up your IO every damn 30 seconds (source). Why didn't you just pick ext4, which is a proven system and has much higher performance?
edit:
I'm still monitoring my downloads in sabnzbd. Download speeds are at ~10MB/s, which is slower than I had on OS4 (12.5 top, which is the limit I have on usenet). But whenever the btrfs processes show up, it's 1KB/s or less. The filesystem is killing performance. Apart from this download and my shell session with top, nothing else is running. Once these processes for the FS sleep, load drops to about 4. Once they wake, it's back up to 7. Heck, during the btrfs slowdown, a simple request to http takes 13 seconds (!!) where the norm is < 150ms.
This is a copy from a game folder in my steam library to the NAS. It is just shy of 6GB in size and contains a large number of small files, as well as a few large ones. I had top open in a putty window while copying.

Every section marked in red, the BTRFS processes were dominating in top. Not just the transaction process, also a flush process, the various endio processes and the md127 process. Once they started floating to the surface, copying would grind to a halt (either below 30KB/s or even complete stops). At those points, I/O wait would also reach 75% on some of the cores. As soon as these processes would terminate (or sleep, whatever), copy would resume and IO wait would go to 2 or 3%, which is normalish.
As I am writing this, I've also restarted my sabnzbd and wait states are below 2%, load on the system is below 3. That is, until btrfs rears it's ugly head again, at which point wait spikes up again. I do not yet dare to re-allow both post-processing (par2, unrar) and downloading at the same time, since the crippled filesystem simply can't cope, where the ext system in OS4 had no trouble at all.
Netgear, this has got to go. BTRFS is not production ready. Heck, you've got a bloody release candidate on these devices (0.20-rc1, btrfs --version for those interested). This system is a disaster. In the time it took me to write four lines, load has spiked up from 2 to 7, simply because ONE process is writing to disk and btrfs can't keep up. The filesystem is using over 7GB for meta data alone, and every time you do something on the device, it increases. Not only that, but it has a scheduled time of locking up your IO every damn 30 seconds (source). Why didn't you just pick ext4, which is a proven system and has much higher performance?
edit:
I'm still monitoring my downloads in sabnzbd. Download speeds are at ~10MB/s, which is slower than I had on OS4 (12.5 top, which is the limit I have on usenet). But whenever the btrfs processes show up, it's 1KB/s or less. The filesystem is killing performance. Apart from this download and my shell session with top, nothing else is running. Once these processes for the FS sleep, load drops to about 4. Once they wake, it's back up to 7. Heck, during the btrfs slowdown, a simple request to http takes 13 seconds (!!) where the norm is < 150ms.
Related Content
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!