Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Straits-cli should display blockdev, pool, and filesystem information in sub-optimal conditions and generally have fuller function than it currently does
Description of problem:
If there is a device failure in a pool, stratis-cli may only return information saying that it couldn't collect information for that pool. The stratis-cli doesn't provide any additional information about the other devices, pools, or filesystems that may exist.
Version-Release number of selected component (if applicable):
RHEL 8.1
Stratisd and Stratis-cli 1.0.4
How reproducible:
Using 2 or more devices, create two stratis pools and one filesystem.
[root@9 ~]# stratis fs
Pool Name Name Used Created Device UUID
p1 fs1 1.95 GiB Jul 16 2019 13:30 /stratis/p1/fs1 89a2d0c4e0674c198a10cf2ab1ec8584
[root@9 ~]# stratis pool
Name Total Physical Size Total Physical Used
p1 3 GiB 2.01 GiB
p2 2 GiB 56 MiB
[root@9 ~]# stratis blockdev
Pool Name Device Node Physical Size State Tier
p1 /dev/loop3 1 GiB InUse Data
p1 /dev/loop4 1 GiB InUse Data
p1 /dev/sda 1 GiB InUse Data
p2 /dev/loop1 1 GiB InUse Data
p2 /dev/loop2 1 GiB InUse Data
[root@9 ~]# mount /stratis/p1/fs1 /strat1
[root@9 ~]# rsync --progress --recursive /usr/ /strat1
[root@9 ~]# echo offline > /sys/block/sda/device/state
[root@9 ~]# sync
The sync causes what is left in the page cache to be flushed, but /dev/sda is offline.
As a result the filesystem and device mapper report problems:
kernel: XFS (dm-5): writeback error on sector 1744885488
kernel: device-mapper: thin: 252:3: switching pool to fail mode
kernel: device-mapper: thin metadata: couldn't read superblock
kernel: device-mapper: thin: 252:3: failed to set 'needs_check' flag in metadata
kernel: device-mapper: thin: 252:3: failed to abort metadata transaction
kernel: XFS (dm-5): writeback error on sector 2013366240
kernel: device-mapper: thin metadata: couldn't read superblock
kernel: device-mapper: thin: 252:3: failed to set 'needs_check' flag in metadata
kernel: device-mapper: thin: 252:3: dm_pool_get_metadata_transaction_id returned -22
stratisd[2223]: WARN libstratis::engine::strat_engine::thinpool::thinpool: Devicemapper could not obtain the status for devicemapper thinpool device 252:3 belonging to pool with UUID c146db62-cb22-4335-aaf6-156ced6db729
stratisd[2223]: ERROR libstratis::engine::strat_engine::thinpool::thinpool: Thinpool status is fail -> Failed
Stratis-cli, when questioned about filesystem, pool, and blockdev returns an execution failure.
[root@9 ~]# stratis fs
Execution failure caused by:
no total physical size computed for pool with uuid c146db62-cb22-4335-aaf6-156ced6db729
[root@c9 ~]# stratis pool
Execution failure caused by:
no total physical size computed for pool with uuid c146db62-cb22-4335-aaf6-156ced6db729
[root@c9 ~]# stratis blockdev
Execution failure caused by:
no total physical size computed for pool with uuid c146db62-cb22-4335-aaf6-156ced6db729
In the logs Stratisd dumps its configuration and it knows that the pool is in a failed state. It also knows
what is configured for filesystem, pool, and blockdev.
stratisd[2223]: INFO stratisd: Dump timer expired, dumping state
stratisd[2223]: DEBUG stratisd: Engine state:
...
pool_state: Failed,
...
Expected results:
Stratis-cli should be able to provide most of the filesystem, pool, and device information
even if it detects a problem with one or a few data points. In this case, stratis-cli
could also report that the pool has failed.
Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1679818#c8.
The problem here is that virtually no CLI commands will fail once it becomes impossible to use the D-Bus GetManagedObjects call to obtain information about the current state.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2020:1634
Description of problem: If there is a device failure in a pool, stratis-cli may only return information saying that it couldn't collect information for that pool. The stratis-cli doesn't provide any additional information about the other devices, pools, or filesystems that may exist. Version-Release number of selected component (if applicable): RHEL 8.1 Stratisd and Stratis-cli 1.0.4 How reproducible: Using 2 or more devices, create two stratis pools and one filesystem. [root@9 ~]# stratis fs Pool Name Name Used Created Device UUID p1 fs1 1.95 GiB Jul 16 2019 13:30 /stratis/p1/fs1 89a2d0c4e0674c198a10cf2ab1ec8584 [root@9 ~]# stratis pool Name Total Physical Size Total Physical Used p1 3 GiB 2.01 GiB p2 2 GiB 56 MiB [root@9 ~]# stratis blockdev Pool Name Device Node Physical Size State Tier p1 /dev/loop3 1 GiB InUse Data p1 /dev/loop4 1 GiB InUse Data p1 /dev/sda 1 GiB InUse Data p2 /dev/loop1 1 GiB InUse Data p2 /dev/loop2 1 GiB InUse Data [root@9 ~]# mount /stratis/p1/fs1 /strat1 [root@9 ~]# rsync --progress --recursive /usr/ /strat1 [root@9 ~]# echo offline > /sys/block/sda/device/state [root@9 ~]# sync The sync causes what is left in the page cache to be flushed, but /dev/sda is offline. As a result the filesystem and device mapper report problems: kernel: XFS (dm-5): writeback error on sector 1744885488 kernel: device-mapper: thin: 252:3: switching pool to fail mode kernel: device-mapper: thin metadata: couldn't read superblock kernel: device-mapper: thin: 252:3: failed to set 'needs_check' flag in metadata kernel: device-mapper: thin: 252:3: failed to abort metadata transaction kernel: XFS (dm-5): writeback error on sector 2013366240 kernel: device-mapper: thin metadata: couldn't read superblock kernel: device-mapper: thin: 252:3: failed to set 'needs_check' flag in metadata kernel: device-mapper: thin: 252:3: dm_pool_get_metadata_transaction_id returned -22 stratisd[2223]: WARN libstratis::engine::strat_engine::thinpool::thinpool: Devicemapper could not obtain the status for devicemapper thinpool device 252:3 belonging to pool with UUID c146db62-cb22-4335-aaf6-156ced6db729 stratisd[2223]: ERROR libstratis::engine::strat_engine::thinpool::thinpool: Thinpool status is fail -> Failed Stratis-cli, when questioned about filesystem, pool, and blockdev returns an execution failure. [root@9 ~]# stratis fs Execution failure caused by: no total physical size computed for pool with uuid c146db62-cb22-4335-aaf6-156ced6db729 [root@c9 ~]# stratis pool Execution failure caused by: no total physical size computed for pool with uuid c146db62-cb22-4335-aaf6-156ced6db729 [root@c9 ~]# stratis blockdev Execution failure caused by: no total physical size computed for pool with uuid c146db62-cb22-4335-aaf6-156ced6db729 In the logs Stratisd dumps its configuration and it knows that the pool is in a failed state. It also knows what is configured for filesystem, pool, and blockdev. stratisd[2223]: INFO stratisd: Dump timer expired, dumping state stratisd[2223]: DEBUG stratisd: Engine state: ... pool_state: Failed, ... Expected results: Stratis-cli should be able to provide most of the filesystem, pool, and device information even if it detects a problem with one or a few data points. In this case, stratis-cli could also report that the pool has failed.