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

mdraid member status not updated #1214

Closed
phillxnet opened this Issue Mar 11, 2016 · 6 comments

Comments

Projects
None yet
3 participants
@phillxnet
Member

phillxnet commented Mar 11, 2016

Once a disk is labelled by Rockstor as an mdraid member that status is not properly updated even if the disk is manually wiped by for example mdadm --zero-superblock /dev/sdX. Thank's to @elmcrest and @Spectre694 in the following forum post for rooting out this issue.
https://forum.rockstor.com/t/disks-failing-with-badge-disk-is-a-mdraid-member/1210/7?u=phillxnet

Please update the referenced forum post with any development on this issue.

@schakrava Since this was my fault I'd welcome the assignment. I haven't had the chance to reproduce locally but pretty sure I neglected proper raid member updates as I was assuming system drive only md id however in this case the label was established on a non system drive from a drives prior mdraid membership: pre rockstor. This required a re-install after manual --zero-superblock to clear the db "mdraid member" flag.

@phillxnet

This comment has been minimized.

Member

phillxnet commented Apr 7, 2016

Another forum thread that appears to have run into the same issue is:
https://forum.rockstor.com/t/formatting-old-raid-hdds/1337
Please also update this thread with development on this issue.

@phillxnet

This comment has been minimized.

Member

phillxnet commented Apr 7, 2016

The initial fix for this need only be updating the db drive entry of mdraid member in the role field on disk re-scan. That would then not necessitate the need for a re-install at least. This would still leave users having to manually execute the --zero-superblock command but would make for a much better arrangement than having to re-install.

@phillxnet

This comment has been minimized.

Member

phillxnet commented May 8, 2016

A less long winded workaround than re-installing would be to run the --zero-superblock via command line on the prior mdraid members then disconnect those same drives and perform a Rescan on the Disks page. Then remove the entries pertaining to the removed drives. This way a fresh db entry will be made upon the drives re-connection, and given they no longer have mdraid superblock info their db entries should be clear of this flag; there by circumventing this bug where a Disks page Rescan fails to update a drives mdraid member status.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 8, 2016

correct logical error on removing mdraid member role rockstor#1214
Previously we only alterred the mdraid member flag to a disks role
when it's fstype, as reported by scan_disks, indicated the need.
However this was done within a conditional that precluded
examining a 'None' fstype which is what scan_disks translates an
empty string into. Hence we never updated a role db entry for a
previous mdraid member once that member no longer returned an
fstype. Resolved by moving the role label logic outside the
previous conditional such that it now applies to all disks even if
they return no fstype from scan_disks.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 8, 2016

add debug logging for issue rockstor#1214
We need now to prove this works as expected
so add additional logging to help.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 9, 2016

update disk model comments - role field as json rockstor#1214
Previously envisioned as space separated values, update
to reflect proposed (by @suman) json format for this
field.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 9, 2016

update disks state using json format for role rockstor#1214
Also add beginnings of accounting for roles other than
mdraid member. Note this element is incomplete here.
N.B. provision is included for dealing with existing
legacy db entries so that they may be updated to the
new json format for this role field.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 9, 2016

update role handlebars helper for json format rockstor#1214
Note that as previous db entries may have non json
format we account for this as before and test for
json format before querying mdraid property existence
in role field.
@phillxnet

This comment has been minimized.

Member

phillxnet commented May 9, 2016

This is now mostly done bar final testing and debug log removal. Ie it resolves this issue and transitions the disks role field to json format as suggested by @schakrava .
I intend to have a quick look at extending things a little further to allow for additional roles in the future, but the base functions are now in place.

@cron410

This comment has been minimized.

cron410 commented May 10, 2016

Phil you are awesome, but does this bring up a larger feature need? Should we start thinking about a "factory reset" option to remove all settings and disks from the DB? This could replace the requirement to reinstall the entire system when weird things happen. A copy of the default DB could be kept as a skel so the factory reset option could just delete the currently running DB and replace it with the factory default one. Just a thought.

@phillxnet

This comment has been minimized.

Member

phillxnet commented May 10, 2016

@cron410 Thanks. This issue does address an error (in my own code) that needed fixing and there was upgrades to be done on the role field so popped them in while I was here.

However your Idea re factory reset is definitely an interesting one and as you say may address these, 'works one way but not the other' type of bugs that require people to re-install, or work around some how, or worse still fiddle with the db directly. I did provide a less long winded work around in my 8th of May comment here but I digress. Factory reset of db is definitely an idea with merit and I like it myself.

Would you like to open an issue on this indicating it as a feature request and how you think it might be implemented from the user perspective at least. Then hopefully a few people can chip in and get the idea flushed out? This might also help with development as it goes since then it would be easier to test a new feature or bug fix on a fresh database such as is experienced directly after install.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 12, 2016

preserve existing drive role info on non mdraid devices rockstor#1214
As the role field was previously used only as an mdraid member
flag mechanism it would wipe all other roles, this was improved
in the case mdriad members having additional roles but all roles
would still be lost on non mdraid members. This is the initial
patch to address roles retention in non mdraid members.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 12, 2016

fix bug where removing mdraid role left empty json content rockstor#1214


As the default db entry and the cheapest value to check is null, make
sure we return to null when we remove the 'mdraid' member role and
it is the last role. Also avoids unnecessary conversion to json and
quicker reads for the majority case (data disks).

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 12, 2016

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 12, 2016

@schakrava schakrava closed this in e1f92ed May 16, 2016

@schakrava schakrava added this to the Looney Bean milestone May 20, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment