Well, this thread already has a "solution," since it was meant to be informational anyway. :) But in the case of the volume that was resyncing but not mounting, the issue was that the disks had been moved between NAS'es. Apparently, the configuration managed by ROS behind the scenes applies a label to the /data volume comprised of the hostid (not the host name, the output of the hostid shell command) and the volume name, usually "data" (for X-RAID), so "hostid:data". ROS uses that volume label to find and mount the /data volume.

But when disks are moved bewteen NAS'es, that label won't match. Apparently, there is logic to detect this, relabel the volume, and adjust the configuration so that things "just work." Only in this case that didn't happen for some reason. And eventually, my ROS install decided that it couldn't mount the /data volume. But mdadm *did* see the device array and was busy resyncing it as before. So this gave the very odd presentation of a volume that wasn't available and yet was. :)

The solution was to manually update the volume label and adjust associated ROS configuration so that the expected label was present and mounted at boot time. Of course, this was conducted by Netgear support over an enabled Support Access shell. :) But just sharing the basic details here for completeness, since you asked.

Oh, and for the record, the rebuild (for second parity stripe) is now at 38%. Holy cow... never ever run these big drives with less than RAID6, folks. I can't imagine what rebuild times are going to be like once I get enough 8TB disks in here to make the second 4TB stripe in the array active. LOL

Question... does the mdadm rebuild benefit at all from additional RAM? I know I've got this particular NAS under some memory pressure since it arrived with only 4GB and my installed addons, plus normal usage, keep used memory (w/o cache) at just over 2GB.

Forum Discussion

Netgear Wi fi extender EX3110