Re: dm-cache: dirty state of blocks in writethrough mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 07/24/2013 12:24 PM, Kumar amit mehta wrote:
On Tue, Jul 23, 2013 at 03:26:08PM +0200, Heinz Mauelshagen wrote:
On 07/23/2013 08:44 AM, Vijarnia, Anil wrote:
Hello,
In Documentation/cache.txt, section 'Updating on-disk metadata' mentions that "If the system crashes all cache blocks will be assumed dirty when restarted".
I am assuming that the above line is relevant for writeback mode only, and in writethrough mode the cache will always be coherent after a crash.
Can someone confirm/reject this assumption?
That's correct

Reason being that the cache never holds any dirty pages in
writethrough mode.
I'm new to storage and would like to know the linux implementation of
writeback policy of disk cache. In case these disk caches are stored in
volatile RAM and we hit system crash, so that cache is gone, but somehow
we have to flush those pending writes to the backend storage, once the
system comes up. How this is achieved in general, Is it through some
kind of metadata that is maintained in a separate area of the disk or it
relies on the file system's journalling capability?

dm-cache maintains it's own metadata keeping track of any cached blocks properties
such as a block being dirty in case of writeback.

If any write in writeback mode hits a cache block, the cache metadata will
reflect that dirty state before the write's being reported to the application.

After a crashed system rebooted, that information is available to flush a
dirty block out on eviction.

Heinz


!!amit

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux