Bug 1415232 - thin-pool target seem not doing commits without any i/o
Summary: thin-pool target seem not doing commits without any i/o
Keywords:
Status: ASSIGNED
Alias: None
Product: LVM and device-mapper
Classification: Community
Component: lvm2
Version: 2.02.169
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Joe Thornber
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 1450419
TreeView+ depends on / blocked
 
Reported: 2017-01-20 16:05 UTC by Zdenek Kabelac
Modified: 2020-09-29 15:23 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1450419 (view as bug list)
Environment:
Last Closed:
rule-engine: lvm-technical-solution?
rule-engine: lvm-test-coverage?


Attachments (Terms of Use)

Description Zdenek Kabelac 2017-01-20 16:05:06 UTC
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

lvs -a   
   shows  90% of data thin-pool usage      -> exact
     and 100% of data thin volume usage    -> exact

let's discard thin device:

blkdiscard  /dev/vg/testLV

lvs -a   
   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.
after
'dmsetup status'  data are instantly corrected to 0/160.


Version-Release number of selected component (if applicable):
4.10.0-0.rc2.git2.1.fc26.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Joe Thornber 2017-04-20 14:35:21 UTC
I've added this test to the test suite.  It passes with my upstream kernel.  Checking with RHEL next.

https://github.com/jthornber/device-mapper-test-suite/commit/272b0e5b78e15f773ea7bccaea293c8a47e685

Comment 2 Joe Thornber 2017-04-20 16:06:58 UTC
It fails with RHEL

Comment 3 Zdenek Kabelac 2017-06-25 09:15:43 UTC
Still reproducible/observed with:

4.12.0-0.rc6.git3.2.fc27.x86_64

Comment 4 Zdenek Kabelac 2020-09-29 15:23:49 UTC
This issue is reproducible on current upstream kernel:  5.9.0-0.rc6.13.fc34.x86_64


Note You need to log in before you can comment on or make changes to this bug.