You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally reported by KarstenV in the following forum thread, with the trigger unidentified at the time; in very specific (and potentially pathological) db state instances all shares (subvols) fail to mount as share_helpers.py import_shares() throws a programmatic error when volume_usage() fails to behave as expected. Having now established at least one possible trigger (specific db state) for the indicated behaviour, this issue is opened to address the robustness of the share mounting mechanism in this scenario. An attempt should be made to track the cause of the db field 'pathology' however in any case all mounts should not fail in this scenario so that is the focus of this issue.
Observed error:
File "/opt/rockstor/src/rockstor/storageadmin/views/command.py", line 271, in post
import_shares(p, request)
File "/opt/rockstor/src/rockstor/storageadmin/views/share_helpers.py", line 83, in import_shares
volume_usage(pool, share.qgroup, share.pqgroup)
ValueError: need more than 2 values to unpack
Resulting in all shares failing to import.
A trigger for this behaviour appears to be a share.pqgroup db value of "-1/-1" which results in volume_usage returning only 2 values when import_shares, as it employs volume_usage's 3 parameter personality, expects 4 values.
Issue authors intended approach to improve robustness in this scenario:
Extend fs/tests/test_btrfs.py test_volume_usage() unit test to reproduce the observed behaviour.
Modify volume_usage to guarantee 'actual parameter count' to 'return value count' mapping and verify this mapping via the extended unit test.
Establish if the trigger db value is 'self healing', ie overwritten, with sane values there after.
In some instances the share.pqgroup db field can contain
the nonsensical '-1/-1'. This unit test extension adds a
call to volume_usage() with this value. This is to prove
a pending fix to volume_usage() and help guard against
future regressions of the same type: volume_usage()
failing to return the expected number of list elements
when passed a non existent qgroupip as 3rd parameter.
phillxnet
added a commit
to phillxnet/rockstor-core
that referenced
this issue
Jul 25, 2017
When called with the 3rd parameter as -1/-1 the expected
output was a 4 element list, however only 2 elements were
returned. Alter to ensure the returned list has 4 elements
when the 3rd parameter is != None. Non existent qgroupid's
are reported as taking no space.
Originally reported by KarstenV in the following forum thread, with the trigger unidentified at the time; in very specific (and potentially pathological) db state instances all shares (subvols) fail to mount as share_helpers.py import_shares() throws a programmatic error when volume_usage() fails to behave as expected. Having now established at least one possible trigger (specific db state) for the indicated behaviour, this issue is opened to address the robustness of the share mounting mechanism in this scenario. An attempt should be made to track the cause of the db field 'pathology' however in any case all mounts should not fail in this scenario so that is the focus of this issue.
Observed error:
Resulting in all shares failing to import.
A trigger for this behaviour appears to be a share.pqgroup db value of "-1/-1" which results in volume_usage returning only 2 values when import_shares, as it employs volume_usage's 3 parameter personality, expects 4 values.
Issue authors intended approach to improve robustness in this scenario:
Please update to the following forum thread with this issues resolution:
https://forum.rockstor.com/t/after-upgrading-to-3-8-16-11-rock-on-wont-start/2842
The text was updated successfully, but these errors were encountered: