From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: [PATCH 0/2] dm thin: Flush data device before committing metadata to avoid data corruption Date: Wed, 4 Dec 2019 15:17:10 -0500 Message-ID: <20191204201710.GA31432@redhat.com> References: <20191204140742.26273-1-ntsironis@arrikto.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com Content-Disposition: inline To: Eric Wheeler Cc: dm-devel@redhat.com, thornber@redhat.com, Nikos Tsironis , agk@redhat.com List-Id: dm-devel.ids On Wed, Dec 04 2019 at 2:58pm -0500, Eric Wheeler wrote: > On Wed, 4 Dec 2019, Nikos Tsironis wrote: > > > The thin provisioning target maintains per thin device mappings that map > > virtual blocks to data blocks in the data device. > > > > When we write to a shared block, in case of internal snapshots, or > > provision a new block, in case of external snapshots, we copy the shared > > block to a new data block (COW), update the mapping for the relevant > > virtual block and then issue the write to the new data block. > > > > Suppose the data device has a volatile write-back cache and the > > following sequence of events occur: > > For those with NV caches, can the data disk flush be optional (maybe as a > table flag)? IIRC block core should avoid issuing the flush if not needed. I'll have a closer look to verify as much. Mike