Bug 1337588

Summary: When *cache* target reports 'clean' state, it then may report dirty blocks on table reload
Product: [Community] LVM and device-mapper Reporter: Zdenek Kabelac <zkabelac>
Component: device-mapperAssignee: Joe Thornber <thornber>
Status: NEW --- QA Contact: cluster-qe <cluster-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 2.02.152CC: agk, heinzm, jbrassow, msnitzer, prajnoha, zkabelac
Target Milestone: ---Flags: rule-engine: lvm-technical-solution?
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Zdenek Kabelac 2016-05-19 14:26:25 UTC 
Description of problem:

While introducing lvm2 support for live change of cache mode I've noticed,
waiting for  'clean' cache even with 'flushing' status still does not
ensure the clean data appears on this.
Table reload from 'cleaner' policy to to use 'passthrough' cache mode is aborted because cache reports dirty blocks:
--
cache metadata: cache block 273 is dirty
table: 253:2: cache: Cannot enter passthrough mode unless all blocks are clean
ioctl: error adding target to table
--

Putting there longer waits or even calling 'sync'  does not fixes it.

Version-Release number of selected component (if applicable):
kernel 4.6
cache v1.9.0

How reproducible:

Steps to Reproduce:
1. create dirty cached device in writaback mode
2. reload with cleaner policy
3. wait for clean cache (status with fluch)
4. try to reload table with passthrough cache mode

Actual results:
Getting errors with dirty block prevent this change

Expected results:
No dirty block reported - operation should pass

Additional info:
As a workaound extra call:
  suspend
  resume 
after 'clean' cache status being reported fixes the problem and allows to proceed. (Lvm2 will add this 'extra' call to ensure backward compatibility,
once kernel is fixes, this extra suspend/resume might be skipped)