Re: add volatile flag to PV/LVs (for cache) to avoid degraded state on reboot

Dne 21. 01. 24 v 3:21 matthew patton napsal(a):
>> As like you already said it was never ACKed, so the software that tried to write it never expected it to be written.
> 
> we don't care about the user program and what it thinks got written or not. 
> That's way higher up the stack.
> 
> Any write-thru cache has NO business writing new data to cache first, it must 
> hit the source media first. Once that is done it can be ACK'd. The ONLY other 
> part of the "transaction" is an update to the cache management block-mapping 
> to invalidate the block so as to prevent stale reads.
> 
> THEN  IF there is a case to be made for re-caching the new data (we know it 
> was a block under active management), that is a SECOND OP that can also be 
> made asynchronous. Write-thru should ALWAYS perform and behave like cache 
> device doesn't exist at all.


Hi

Anyone can surely write a caching policy following rules above, however 
current DM cache is working differently with cached 'blocks'.

Method above would require to drop/demote whole cached block out of the cache 
first. Then update the content on the origin device, and promote the whole 
such updated block back to cache. i.e. user writes sector 512b  and the cached 
block with 512KiB would need to be recached...

So here I could wish a good luck with performance of such engine, the current 
DM cache engine is using parallel writes - thus there can be a moment where 
the cache has simply the more recent and valid data.

The problem here will happen when origin would have faulty sectors - so DM 
target takes this risk - it should not have any impact on properly written 
software that is using transactional mechanisms properly.

So if there is a space for much slower caching that will never ever have any 
dirty pages - someone can bravely step-in and write a new caching policy for 
such engine.

Regards

Zdenek