Cannot import degraded pool info after OS reinstall

shocker · May 15, 2020, 10:36am

Hello,
Forgot about this one

Scenarios to reproduce:

Degraded pool RAID56 (I think it can be any type of degraded pool but at least to be able to mount it as degraded).
Reinstall Rockstor with OpenSUSE Leap 15.2 (Don’t think that this is a distro related thing).
Go to Storage -> Disks -> And click import pool info from one of the HDDs. An error will occur and Rockstor will not be able to do this.
If you mount the pool manually from CLI in a degraded state, then Rockstor can successfully import the pool information.

As this seems to be more like a future then a bug, it will be nice instead of the error to have a message as most of the unskilled users will have trouble to work around this. A nice popup with "before importing pool information type in CLI “# mount -t btrfs -o degraded /dev/[disk that was clicked] /mnt2/mountpoint”.

Cheers

phillxnet · May 15, 2020, 11:42am

@shocker Hello again.

I can chip in on this one.

Yes, this capability was added in the following:

github.com/rockstor/rockstor-core

allow import of ro,degraded cli mounted pool. Fixes #1890

rockstor:master ← phillxnet:1890_allow_import_of_ro,degraded_cli_mounted_pool

opened 06:00PM - 11 Feb 18 UTC

phillxnet

+83 -42

Facilitates the import of a prior cli mounted pool, this enables the ability to …use initial mount options that are currently not available via the Web-UI prior to an import. The focus here is to enable an import of a pool that requires, for example, ro,degraded mount options. 1. Fix import failure (prior TODO:) via Read-only quota enable attempt on import. 2. Fix failure on qgroup assign on ro fs and avoid these and related calls from higher level functions via (4) below. 3. Improves code consistency re PQGROUP_DEFAULT use. 4. Make additional use of the existing quota disabled mechanism to improve ro behaviour during import and subsequent share/snap refresh. 5. Avoid assigning pqgroups within db that failed creation due to ro fs. 6. Improve quota disabled robustness re redundant e.rc checks from btrfs command execution as per a previous pr code review (see pr #1874) 7. Improve / update code comments. 8. Improve pqgroup/quota management. Fixes #1890 Please see issue text for further context. @schakrava Ready for review. Tested by creating a 2 disk "rock-pool" (raid1) Shares: - rock-share - rock-share-clone Snaps: - rock-share-snap - rock-share-snap-rw - rock-share-clone-snap System was power cycled during which both disks were removed. Upon boot both "detached-..." disk entries were removed and pool / share refresh to ensure all entries were removed. One of the raid1 members was re-attached and the system booted up again. All prior mount points were removed: - chattr -i /mnt2/rock-{pool,share,share-clone} - rm -rf /mnt2/rock-{pool,share,share-clone} Cli mount to facilitate currently Web-UI impossible mount options prior to import: N.B. as per Rockstor standard locations re vol label: Make initial mount point either via UI attempted import or via: - mkdir /mnt2/rock-pool Mount ro,degraded via cli as per Rockstor expected location: - /bin/mount -o ro,degraded /dev/disk/by-label/rock-pool /mnt2/rock-pool An import via the Web-UI was enacted and pool, share, snap state verified to be as expected. The above test method was also carried out with the addition of the rock-pool having quotas disabled prior to ro,degraded mount: - btrfs quota disable /mnt2/rock-pool to ensure that we have functional quota disabled ro,degraded import capability.

Agreed, at least we should have some indication of this in the docs. But so we have a record here, the solution it so mount, as you indicated (almost), in the expected mount point of:

/mnt2/pool-label

As Rockstor checks to see if a mount at that point exists first, and if not then it goes for that mount and then fails. So if it’s already there, using the ‘by hand’ degraded or what ever, there we have an effective work around.

Definitely needs re-visiting re usability, thanks for bringing this up and sharing your findings. Much appreciated. The first step here would be advise on this in the docs as the code side will take a little longer. And if anyone fancies jumping in there code wise, be advised that I’m currently making fairly major changes to some of the associated code, btrfs.py at least, in my current pending/ongoing pull request to improve things ready for the Stable Channel rpm release on openSUSE. There after would be a good time to look again I’d say as that file will then have been moved to our new black formatting that is slowly becoming a project wide ‘feature’ as each issue changes files. We also have some preparation ongoing for the Python 2 to 3 move. So we really need to get that all lined up ready to more easily accommodate these nice-to-haves. However, this may be a relatively easy ‘catch’, and as you say would be a nice feature, especially for those less familiar.

Cheers.

shocker · May 15, 2020, 12:13pm

Yup this can be easily reproduced on a VM. Let me know when the beta is out with all the goodies to try it out. I don’t mind breaking the GUI on my server as most of the time I’m using CLI