Our ReadyNAS stopped being responsive yesterday and required a reboot. It wouldn't respond to an SSH reboot request so we power cycled it. Upon reboot, all our shares were gone, as were our app settings. The only way we found to recreate the shares was to move the data directories, create the share and then move the data back.
Is there a better way to do this? Because of the horrible speed of btrfs moving files, this took a very long time. How can we create a share with a directory that already exists? Also, how can we ensure our shares don't disappear when we reboot?
Is there a better way to do this? Because of the horrible speed of btrfs moving files, this took a very long time. How can we create a share with a directory that already exists?
Each share is a BTRFS subvolume, and moves between subvolumes end being copy+delete.
If you are moving with ssh, then cp with the --reflink option is much faster (the speed you expect from a move). The --reflink uses the btrfs CoW features, so the new copy shares the data blocks with the original. You can then delete the original.
If the subvolume is intact, you can also rename it with ssh, then create the share. Then delete the newly created subvolume with ssh, and rename the original back.
So the better way would have been to locate the root cause and fit it. Then you wouldn't have had to move the data between subvolumes. This could have been a corrupt config file somewhere or broken database.
Unfortunately, to locate the root cause, you need to know how to troubleshoot the ReadyNAS OS (or at least a Linux machine as well as BTRFS).
@jak0lantash wrote: you need to know how to troubleshoot the ReadyNAS OS
Easy to say I guess, but I've never seen any information here on how to repair a broken database. And how would a non-Netgear employee be able to tell that the a bad config file was the root cause (something else in the application might have screwed up that config file).
So as far as I can see this just turns into "contact paid support". I'd likely have done the workaround myself (or done a full reset).
If everything's fixed now (now that you've done a workaround that's not recommended) and you have a good backup you should probably update the firmware in case it was an issue that's already been fixed. The latest firmware is 6.7.1.
One possible cause would relate to a temporarily filled 4GB root volume.
