From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Vijarnia, Anil" Subject: dm-cache: dirty state of blocks in writethrough mode Date: Tue, 23 Jul 2013 06:44:41 +0000 Message-ID: Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6239836480377486894==" Return-path: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: "dm-devel@redhat.com" List-Id: dm-devel.ids --===============6239836480377486894== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_C91EDD5251EDF44CB434B1039B0DEEB82A8D0762SACEXCMBX02PRDh_" --_000_C91EDD5251EDF44CB434B1039B0DEEB82A8D0762SACEXCMBX02PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, In Documentation/cache.txt, section 'Updating on-disk metadata' mentions th= at "If the system crashes all cache blocks will be assumed dirty when resta= rted". 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? Thanks --_000_C91EDD5251EDF44CB434B1039B0DEEB82A8D0762SACEXCMBX02PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

In Documentation/cache.txt, section ‘Updating on-disk metadata&#=
8217; mentions that “If the system crashes all cache blocks will be a=
ssumed 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?

Thanks

--_000_C91EDD5251EDF44CB434B1039B0DEEB82A8D0762SACEXCMBX02PRDh_-- --===============6239836480377486894== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============6239836480377486894==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinz Mauelshagen Subject: Re: dm-cache: dirty state of blocks in writethrough mode Date: Tue, 23 Jul 2013 15:26:08 +0200 Message-ID: <51EE8470.6070302@redhat.com> References: Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3408786159625775778==" 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 To: device-mapper development List-Id: dm-devel.ids This is a multi-part message in MIME format. --===============3408786159625775778== Content-Type: multipart/alternative; boundary="------------000409000702040600070803" This is a multi-part message in MIME format. --------------000409000702040600070803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. -- lvmguy > > Thanks > > > > > > > > -- > dm-devel mailing list > dm-devel@redhat.com > https://www.redhat.com/mailman/listinfo/dm-devel --------------000409000702040600070803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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.

-- lvmguy

Thanks

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

--------------000409000702040600070803-- --===============3408786159625775778== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============3408786159625775778==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kumar amit mehta Subject: Re: dm-cache: dirty state of blocks in writethrough mode Date: Wed, 24 Jul 2013 06:24:53 -0400 Message-ID: <20130724102452.GA6963@gmail.com> References: <51EE8470.6070302@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <51EE8470.6070302@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Heinz Mauelshagen , o@gmail.com Cc: dm-devel@redhat.com List-Id: dm-devel.ids 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? !!amit From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinz Mauelshagen Subject: Re: dm-cache: dirty state of blocks in writethrough mode Date: Wed, 24 Jul 2013 19:05:59 +0200 Message-ID: <51F00977.7060802@redhat.com> References: <51EE8470.6070302@redhat.com> <20130724102452.GA6963@gmail.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130724102452.GA6963@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Kumar amit mehta Cc: dm-devel@redhat.com, o@gmail.com List-Id: dm-devel.ids 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kumar amit mehta Subject: Re: dm-cache: dirty state of blocks in writethrough mode Date: Wed, 24 Jul 2013 09:02:20 -0400 Message-ID: <20130724130220.GC6963@gmail.com> References: <51EE8470.6070302@redhat.com> <20130724102452.GA6963@gmail.com> <51F00977.7060802@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <51F00977.7060802@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Heinz Mauelshagen Cc: dm-devel@redhat.com List-Id: dm-devel.ids On Wed, Jul 24, 2013 at 07:05:59PM +0200, Heinz Mauelshagen wrote: > 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. Ahh, so It is the metadata device. Maybe overkill, but is it possible to keep redundant copies of this metadata, like user space utilities such as LVM2 does? !!amit From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinz Mauelshagen Subject: Re: dm-cache: dirty state of blocks in writethrough mode Date: Thu, 25 Jul 2013 12:45:31 +0200 Message-ID: <51F101CB.20900@redhat.com> References: <51EE8470.6070302@redhat.com> <20130724102452.GA6963@gmail.com> <51F00977.7060802@redhat.com> <20130724130220.GC6963@gmail.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130724130220.GC6963@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Kumar amit mehta Cc: dm-devel@redhat.com List-Id: dm-devel.ids On 07/24/2013 03:02 PM, Kumar amit mehta wrote: > On Wed, Jul 24, 2013 at 07:05:59PM +0200, Heinz Mauelshagen wrote: >> 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. > Ahh, so It is the metadata device. Maybe overkill, but is it > possible to keep redundant copies of this metadata, like user space > utilities such as LVM2 does? You can set up a mirrored metadata device to be resilient against SSD failures. Plus you can take metadata snapshots at arbitrary points in time; see the targets kernel documentation in thin-provisioning.txt for this and the recent thin_dump support metadata snapshots in the rawhide device-mapper-persistent-data package. Either is subject to future LVM2 support and isn't supported as yet. Heinz > > !!amit From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kumar amit mehta Subject: Re: dm-cache: dirty state of blocks in writethrough mode Date: Thu, 25 Jul 2013 22:45:46 -0400 Message-ID: <20130726024546.GA8707@gmail.com> References: <51EE8470.6070302@redhat.com> <20130724102452.GA6963@gmail.com> <51F00977.7060802@redhat.com> <20130724130220.GC6963@gmail.com> <51F101CB.20900@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <51F101CB.20900@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Heinz Mauelshagen Cc: dm-devel@redhat.com List-Id: dm-devel.ids On Thu, Jul 25, 2013 at 12:45:31PM +0200, Heinz Mauelshagen wrote: > You can set up a mirrored metadata device to be resilient against > SSD failures. Okay > Plus you can take metadata snapshots at arbitrary points in time; > see the targets kernel documentation in thin-provisioning.txt for this > and the recent thin_dump support metadata snapshots in the rawhide > device-mapper-persistent-data package. > So these feature is already upstream and also in fedora 20, but not in Red Hat 6.4 yet ? > Either is subject to future LVM2 support and isn't supported as yet. So, if LVM2 doesn't support it as of now, Any idea if EVMS or any other volume Managers consume these features? !!amit From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinz Mauelshagen Subject: Re: dm-cache: dirty state of blocks in writethrough mode Date: Fri, 26 Jul 2013 13:14:01 +0200 Message-ID: <51F259F9.1090107@redhat.com> References: <51EE8470.6070302@redhat.com> <20130724102452.GA6963@gmail.com> <51F00977.7060802@redhat.com> <20130724130220.GC6963@gmail.com> <51F101CB.20900@redhat.com> <20130726024546.GA8707@gmail.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130726024546.GA8707@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: device-mapper development List-Id: dm-devel.ids On 07/26/2013 04:45 AM, Kumar amit mehta wrote: > On Thu, Jul 25, 2013 at 12:45:31PM +0200, Heinz Mauelshagen wrote: >> You can set up a mirrored metadata device to be resilient against >> SSD failures. > Okay > >> Plus you can take metadata snapshots at arbitrary points in time; >> see the targets kernel documentation in thin-provisioning.txt for this >> and the recent thin_dump support metadata snapshots in the rawhide >> device-mapper-persistent-data package. >> > So these feature is already upstream and also in fedora 20, but not in > Red Hat 6.4 yet ? No, it's planned for RHEL7. > >> Either is subject to future LVM2 support and isn't supported as yet. > So, if LVM2 doesn't support it as of now, Any idea if EVMS or any other > volume Managers consume these features? None that I'm aware of. Use dmsetup for early testing. We'll support it in LVM2 later in the year. Heinz > > !!amit > > -- > dm-devel mailing list > dm-devel@redhat.com > https://www.redhat.com/mailman/listinfo/dm-devel