From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 16 Feb 2012 10:54:33 -0500 From: Mike Snitzer Message-ID: <20120216155433.GB13948@redhat.com> References: <4F3D03AE.2050502@mohawksoft.com> <20120216135702.GA6212@redhat.com> <4F3D15CC.1080901@mohawksoft.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Subject: Re: [linux-lvm] Snapshots Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Stuart D. Gathman" Cc: LVM general discussion and development On Thu, Feb 16 2012 at 10:18am -0500, Stuart D. Gathman wrote: > Long ago, Nostradamus foresaw that on Feb 16, Mark Woodward would write: > > >I guess I missed that. I need to check out the changes, looks like > >you have auto-grow with monitoring? I was looking more towards the > >"snapshots of snapshots" ability. Is that on the radar? > > The ZumaStor 3rd party userland tools support that. Now AFAIK ZumaStor is a dead technology... nobody is actually maintaining the code upstream. The shared snapshot store that dm-thin-pool provides is functionally equivalent to what Zumastor provides -- dm-thinp provides a single storage pool for all snapshots. This avoids excessive copy-out that the old dm-snapshot suffered from due to it requiring a distinct snapshot store for each snapshot. I'd really like to encourage you and others to evaluate and test snapshots with dm-thinp -- now that lvm2 provides support it _should_ be more approachable. > An elegant part of the LVM system is that the device mapper kernel support is > very general, and new data structures can be experimented with entirely in user > code - with a script language even. Metadata for experimental structures does > not have to stored with the main metadata. Please note that the dm-thinp code has metadata in the kernel (on-disk format for btrees, etc) much like a filesystem would have. So there is both kernel and userspace (lvm2) metadata for dm-thinp. Mike