6.7.0 problems with readyDR, GUI access and display

[vandermerwe]

Since upgrading my primary unit (316) and my backup unit (Ultra 6 plus) to 6.7.0 I have had problems with GUI access to both units and Ready DR jobs are not running to schedule. 

The GUI also does not show any information about the disk space consumed by each share (the Available and Consumed columns are empty), nor does it show volume space occupied by snapshots.  This is the case on both units even though I've put 6.7.1 beta onto one of them. Then there is the already reported problem with the disk info display on the Performance page.

I have disabled volume quota but I still run into problems with one of the ReadyDR jobs encountering an input/output error. After this happens none of the ReadyDR jobs runs when scheduled.  The jobs run when manually started but there seems to be a problem with a snapshot on the share that encounters the rrro that then leads to a failure to delete the Ready DR share (which I want to do because there is a discrepancy between the actual number of snapshots and the backed up snapshots (a difference of 1 snapshot))  I get a snapshot deletion failure error. 

I have factory defaulted the backup unit twice now with the same problem.

I have now put the new 6.7.1 beta firmware on the backup unit (after a 3rd factory default) in the hope that this will fix this problem.  However I am afraid to recreate and run the ReadyDR jobs as the only way to overcome the "snapshot deletion error " problem is another factory default.  

Really disappointing as everything including ReadyDR had been working well on 6.6.1

1. Is the 6.7.1 beta suitable for use on my primary unit - I am anxious that the problems with 6.7.0 will put my primary unit data at risk?

2. Is there a solution to the "snapshot deletion failure" error that does not involve a factory default - if there is then I would be more inclined to use the ReadyDR feature again.  Currently it is more trouble than it's worth for me, I want my backups to just work.  I had problems with ReadyDR when it was released which were solved by a firmware fix, but now there seem to be new issues. 

[mdgm-ntgr]

Showing the space consumed by snapshots relies on having volume quotas enabled.

If you can reproduce this on 6.7.1 Beta please send your logs from each unit in (see the Sending Logs link in my sig) both before and after trying to delete the share.

[vandermerwe]

Ok I see quota needs to be enabled to see any utilisation information.

I will try to reproduce again.

[jak0lantash]

To distinguish the quota value set on the shares and the quota feature at the volume level, I usually call the latter "quota accounting". I don't pretend it's 100% accurate but I think it describes better what it does and is a little bit less confusing than just "Quota" (as named in the GUI).

To be able to enforce a quota on a dataset, BTRFS needs to know the space usage for the dataset. So quota accounting is about keeping track of all space usage for the dataset. That's what ReadyNAS OS uses to display the space used per share in the GUI. If you disable quota accounting (at the volume level), then the space usage isn't accounted for and ReadyNAS OS can't display it.

[vandermerwe]

Thanks for the replies.

I have reproduced the input /output error problem.  Essentially I reset the nas, including READYDR jobs.  They were each started manually and ran normally to completion with the correct number of snapshots copied.

Tonight was the first scheduled automatic run and they all failed with input/output errors.  When I manually started each they all ran normally and backed up the latest snapshot from the source nas.

There were no specific entries in the job histories, and deletion of one of the jobs and its share worked without a snapshot deletion error, however I was expecting this as all the snapshots from the source had been backed up.

I have sent in logs, and will continue to try to reproduce the snapshot deletion error.

Spindown is enable on both NAS units with the spinup to create snapshot box ticked on both.

[Skywalker]

Thanks for sending the logs.  The I/O errors are due to a boot-time race condition.  The Marvell NIC driver on the legacy units takes a while to initialize, so the ReadyDR service ends up starting and kicking off the scheduled jobs about 1 second before you get an IP address.  We should have a fix for 6.7.1 Beta 2.

[vandermerwe]

Thanks.

This didn't happen before 6.7.0, did something change?

The IP address is static, clearly this makes no difference.

[Skywalker]

Lots of things can affect service timing with an asynchronous boot process.  It's currently less than 1 second away from working, so a very small change, or even pure randomness could tip it from working to not working with a job that runs immediately after the service starts.