With 6.4.1 I tried to do a backup to a USB3 disk connected to the back port. It was impossibly slow and the admin pages falied to connect or was also very slow. Went to 6.4.2 beta. Same problem. Eventually reformatted the external disk as EXT4, and it seems to be working OK now. At least the backup seems to be progressing , and the GUI is responsive. I was using NTFS (formatted on a windows system).
Seems to me there is a major problem with the NTFS driver on the 104.
... The service for the web admin page is low priority.
I think the evidence is growing that it is set too low. We are seeing reports of stalled admin pages even from RN300 and RN500 owners, correct? If you can't access the web UI, you basically can't do any troubleshooting.
USB backups use a lot of resources and NTFS would use more than a native linux filesystem such as EXT4.
The 100 series is a cost effective device and the service for the web admin page is low priority.
How slow was the backup when using NTFS? Was it still progressing albeit slowly?
The backup was so slow, and the admin GUI so unresponsive that I don't know what was happening. I switched to EXT4 and the backup (about 2.5GB) took over 24 hours but did complete OK.
This sounds doubtful of a specific 6.4.2 problem and more-so some kind of filesystem fragmentation. Specifically, if you're backing up something that has a high level of fragmentation, it'll slow down your box to crawl speeds while it reads and writes that data.
Can you post some info from your btrfs.log showing metadata info to confirm if that is an issue?
Do you do any regular volume maintenance, like defrag/balance? What's your typical write pattern? Do you have a lot of snapshots?
... The service for the web admin page is low priority.
I think the evidence is growing that it is set too low. We are seeing reports of stalled admin pages even from RN300 and RN500 owners, correct? If you can't access the web UI, you basically can't do any troubleshooting.
Not really. ReadyNAS 100 series devices are single core and realistically only have 256mb of RAM after normal services are loaded.
The priority on the Admin Page is irrelevant when the unit is overloaded and processing more than it can handle at any particular moment. Data access is a higher priority than the web interface.
You can always try and pull the logs through RAIDar, or for more advanced users, have SSH enabled to do some troubleshooting.
This sounds doubtful of a specific 6.4.2 problem and more-so some kind of filesystem fragmentation. Specifically, if you're backing up something that has a high level of fragmentation, it'll slow down your box to crawl speeds while it reads and writes that data.
Can you post some info from your btrfs.log showing metadata info to confirm if that is an issue?
Do you do any regular volume maintenance, like defrag/balance? What's your typical write pattern? Do you have a lot of snapshots?
Can't show logs as I ended up formatting the USB disk EXT4 and backing up the whole lot again (took about 24 hours). If you mean fragmentation of the NTFS volume on the NAS, then I don't see how that would happen as it was a straight backup from my PC.
No regular maintenance. No snapshots. Write pattern - just simpe backups from 2 PC's of a bunch of folder to shares on the NAS.
The unit is just a 104 with 3 disks - now about half full.
The backup to EXT4 went fine, and subsequent backups progress OK.
...Data access is a higher priority than the web interface.
Not if you are the admin. And SSH use of course has support implications.
I get that when the unit is overloaded everything stalls no matter what the priority is. But I don't think the web interface should ever stall during maintenance operations (including backup) - from a user perspective, that looks like a bug.
