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

improve root not in partition behaviour #1164

Closed
phillxnet opened this Issue Feb 13, 2016 · 4 comments

Comments

Projects
None yet
1 participant
@phillxnet
Member

phillxnet commented Feb 13, 2016

With an mdraid install (system disk) where root (btrfs) is on for example md126, ie not in a partition, the Disks page fails to display the system disk and the rockstor_rockstor pool is also not found.
I have made a start on modifying scan_disks to account for this arrangement to improve reporting of the system disk and the associated rockstor_rockstor pool.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue Feb 13, 2016

initial scan_disks changes to help deal with non part root rockstor#1164


Comments and start of changes to allow for non partition
based root (/) mount. Includes logging to assist with issue
development.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue Feb 13, 2016

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue Feb 13, 2016

avoid potential key error by checking first rockstor#1164
If this is the first time we are looking at our base device
then there will be no previous record to account for this
by searching first through our list-so-far of scanned and
relevant devices.
@phillxnet

This comment has been minimized.

Member

phillxnet commented Feb 13, 2016

OK, got to break off from this for a bit but hope to return in next day or so to complete:-
Progress so far:-
root-on-base-dev-with-btrfs
The system disk is now visible in Disks and rockstor_rockstor pool is also now identified and displayed as expected.
Flags all seem appropriate so far but need further checking.
N.B. this is a btrfs / on md125 device directly ie not in a partition on that device.

Remaining issues

  • check we have no regressions on regular system drive install arrangements (ie non md and in a partition for example the default sda3 / mount point)
  • make sure comments are consistent with new logic re / not having to be in a partition.
  • reconsider a very recent ext4 root clause removal in the light of this new capability, ie if we can now install system disk on md devs as btrfs via standard installer (with a bit of manual encouragement (cli)) then do we any longer need to revert the hastily removed (by me) ext4 root possibility.
  • also test on a bios raid install as it shares md names but has partitions on those md devs as we may have regressions there.
@phillxnet

This comment has been minimized.

Member

phillxnet commented Feb 14, 2016

N.B. patch set currently broken as causes scan_disks() to NOT report our interest in non root whole disk btrfs, ie our data drives! Will look to this next.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue Feb 15, 2016

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue Feb 15, 2016

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue Feb 15, 2016

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue Feb 15, 2016

restore correct behaviour re non system disk btrfs devices rockstor#1164


Having removed partition clauses to allow for non partition based /
in an earlier commit we need to re-capture btrfs data disks to
repair regression of non system disk btrfs no longer being
flagged as interesting by scan_disks(). Also update local comment to
reflect recent changes in scan logic affecting this section.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue Feb 15, 2016

back propagate to base dev linux_raid_member fstype rockstor#1164
This allows us to identify mdraid members from their partitions
involvement in an md array, this is not needed for bios raid as the
base device is already labeled but with this patch we can assess
base disks involvement in md devs either directly in the case of
bios raid or indirectly in the case of pure software mdraid but in
both cases by looking at the base dev's fstype as returned by
scan_disks().
@phillxnet

This comment has been minimized.

Member

phillxnet commented Feb 15, 2016

Next step is to use the new info re mdraid member disks returned from the patched scan_disks() in _update_disk_state() which I have to modify for this purpose, along with a Disks model extension so that we can have disks.js know from the expanded Disks model that our mdraid host drives are not to be wiped but identified for what they are.

I hope to continue with this tomorrow. The expanded Disks model should also be useful for identifying / tagging drives in the db for special purposes, ie outside of the current btrfs data drives or system drive / drives.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue Feb 16, 2016

add role and smart_options fields to Disk model rockstor#1164
The role field allows us to tag drives when we currently only have
parted which is already overloaded. Used here to identify mdraid
members for pure and bios raid arrays. To cut down on model changes
during upgrades the smart_options was added at the same time; this
is to be used for custom smart parameters required for some drives:
mainly external usb caddy arrangements.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue Feb 16, 2016

populate disk.role with fstype type when used as raid member indicator
…rockstor#1164

Use the fstype from scan_disks to establish role as the same when
fstype gives indication (from scan_disks) that a device is a raid member.
Primarily used to inform UI logic of appropriate indicator in Disks page.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue Feb 16, 2016

Use disk.role to indicate device mdraid member status rockstor#1164
Currently only identifies mdraid fstypes for intel bios raid and
pure software mdraid devices. Relies on recent changes in
scan_disks() that help flag base mdraid devices with their
partitions membership in the same.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue Feb 16, 2016

remove logging used in this issue rockstor#1164
Also remove unused variable and improve comments.
@phillxnet

This comment has been minimized.

Member

phillxnet commented Feb 16, 2016

@schakrava Looks like this is now working as intended and I don't see any regressions.
Last db role field bit was needed to flag raid members ie before we would see:-
bios-raid-before-raid-info-icon
And after additional role we have:-
bios-raid-after-raid-info-icon
Simple info icons by raid members but better than offering to delete our raid members of the system disk.

The following shows the above removed drive after it is re-attached:-
bios-raid-after-missing-btrfs-reattached
so we have working wipe or import flags.
And the following is after that same re-attached drive is imported:-
bios-raid-after-pool-import
N.B. the innostor is an Official Rockstor USB install stick used to test flagging a partitioned drive.

And finally a pure software mdraid, ie btrfs directly on md125 which is made from a partition on each of sda and sdb as is swap and boot, vda in this case has a partition and non btrfs on to indicate the cog flagging and the removed drive is to test that flag:-
mdraid-drive-flags

Normal non mdraid system disk install ie sda3 has also been manually tested as working as expected.

On the above basis I will prepare a pr ready for review.

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