Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rogue share.pqgroup db field fails share mounts #1769

Closed
3 tasks done
phillxnet opened this issue Jul 25, 2017 · 1 comment
Closed
3 tasks done

rogue share.pqgroup db field fails share mounts #1769

phillxnet opened this issue Jul 25, 2017 · 1 comment
Assignees
Labels
Milestone

Comments

@phillxnet
Copy link
Member

phillxnet commented Jul 25, 2017

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.

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

@phillxnet phillxnet changed the title rouge share.pqgroup db field fails share mounts rogue share.pqgroup db field fails share mounts Jul 25, 2017
@phillxnet
Copy link
Member Author

I am currently working on this issue.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue Jul 25, 2017
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.
schakrava added a commit that referenced this issue Jul 31, 2017
…ield_fails_share_mounts

rogue share.pqgroup db field fails share mounts. Fixes #1769
@schakrava schakrava added the bug label Aug 1, 2017
@schakrava schakrava added this to the Point Bonita milestone Aug 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants