Description of problem:
Reporting of status with noflush (dmsetup status --noflush) seems to never get the 'correct' status even after long waiting and no i/o to thin-pool.
Flushing status is needed to enforce commit.
Example of issue (having VG 'vg')
lvcreate -T -L10 vg/pool -V9 -n testLV
dd if=/dev/zero of=/dev/vg/testLV bs=1M count=9
shows 90% of data thin-pool usage -> exact
and 100% of data thin volume usage -> exact
let's discard thin device:
shows 90% of data thin-pool usage -> this is not exact
and 0% of data thin volume usage -> this is OK
lvm2 dropped usage of 'flushing' when obtaining status and there is opened bug 1358314 to rather add support for some 'explicit' flushing logic later.
But there was assumption that in some short period of time
we will obtain valid data anyway - but even after minutes
'dmsetup status --noflush / lvs -a' is still showing 144/160 usage.
'dmsetup status' data are instantly corrected to 0/160.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
I've added this test to the test suite. It passes with my upstream kernel. Checking with RHEL next.
It fails with RHEL
Still reproducible/observed with:
This issue is reproducible on current upstream kernel: 5.9.0-0.rc6.13.fc34.x86_64