Thanks, Joe. So just to make sure I've understood correctly, if the SSD cache is configured as a write-back cache but the device cache is disabled/set to write-though on the HDD and the SSD, then there is no risk of data loss in the event of a failure. Is my understanding correct?
On Tue, Mar 3, 2015 at 4:19 PM, Joe Thornber <thornber@xxxxxxxxxx> wrote:
If the mappings change, ie. something is promoted to the cache, orOn Tue, Mar 03, 2015 at 03:53:39PM +0000, Thanos Makatos wrote:
> On Tue, Feb 17, 2015 at 12:15 PM, Thanos Makatos <thanos.makatos@xxxxxxxxx>
> wrote:
>
> > Hi,
> >
> > I'm trying to understand the failure semantics of dm-cache in write-back
> > mode. In Documentation/device-mapper/cache.txt it is stated:
> >
> > "On-disk metadata is committed every time a FLUSH or FUA bio is written.
> > If no such requests are made then commits will occur every second. This
> > means the cache behaves like a physical disk that has a volatile write
> > cache. If power is lost you may lose some recent writes. The metadata
> > should always be consistent in spite of any crash."
> >
> > Which I admit confuses me. Assumie that no FLUSH/FUA requerst is issued
> > (e.g. the user of the cached device is a Windows VM) and a failure occurs
> > (e.g. there is a power failure but both the HDD and the SSD are fine)
> > immediatelly after a write I/O request, but before on-disk metadata get
> > commited (e.g. the failure occurs less than a second after the write I/O
> > request was completed). After the hosts reboots, is this completed write
> > I/O request going to be lost?
> >
>
> I haven't gotten any reply to this so I'll try to rephrase: If the user of
> the cache doesn't issue FLUSH/FUA, is there a chance of (irreversible) data
> loss in the event of a kernel crash or power failure?
demoted from it. Then the metadata update is committed and updated
before the triggering io is issued.
So power failure will not result in loss of a mapping, it may result
in loss of data if your physical device has a write cache. But this
is also the case with the cache.
- Joe
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
