FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 06-19-2012, 02:43 PM
Alasdair G Kergon
 
Default Ext4 and xfs problems in dm-thin on allocation and discard

On Tue, Jun 19, 2012 at 10:19:33AM -0400, Ted Ts'o wrote:
> One of the things which would be nice to be able to easily set up is a
> configuration where we get the benefits of thin provisioning with
> respect to snapshost, but where the underlying block device used by
> the file system is contiguous.

We're tracking this requirement (for lvm2) here:
https://bugzilla.redhat.com/show_bug.cgi?id=814737

Alasdair

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 06-19-2012, 03:28 PM
Mike Snitzer
 
Default Ext4 and xfs problems in dm-thin on allocation and discard

On Tue, Jun 19 2012 at 10:43am -0400,
Alasdair G Kergon <agk@redhat.com> wrote:

> On Tue, Jun 19, 2012 at 10:19:33AM -0400, Ted Ts'o wrote:
> > One of the things which would be nice to be able to easily set up is a
> > configuration where we get the benefits of thin provisioning with
> > respect to snapshost, but where the underlying block device used by
> > the file system is contiguous.
>
> We're tracking this requirement (for lvm2) here:
> https://bugzilla.redhat.com/show_bug.cgi?id=814737

That is an lvm2 BZ but there is further kernel work needed.

It should be noted that the "external origin" feature was added to the
thinp target with this commit:
http://git.kernel.org/linus/2dd9c257fbc243aa76ee6d

It is start, but external origin is kept read-only and any writes
trigger allocation of new blocks within the thin-pool.

We've talked some about the desire to have a fully provisioned volume
that only starts to get fragmented once snapshots are taken. The idea
is to move the origin into the data volume, via mapping, rather than
copying:

Dec 14 10:37:08 <ejt> we then build a data dev that consists of a linear mapping to that origin
Dec 14 10:37:12 <ejt> plus some extra stuff
Dec 14 10:37:23 <ejt> (the additonal free space for snapshots)
Dec 14 10:37:49 <ejt> we then prepare thinp metadata with a mapping to that origin

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 06-19-2012, 04:03 PM
Alasdair G Kergon
 
Default Ext4 and xfs problems in dm-thin on allocation and discard

On Tue, Jun 19, 2012 at 11:28:56AM -0400, Mike Snitzer wrote:
> That is an lvm2 BZ but there is further kernel work needed.

In principle, userspace should already be able to handle the replumbing I
think. (But when we work through the details of an online import, perhaps
we'll want some further kernel change for atomicity/speed reasons? In
particular we need to be able to do the last part of the metadata merge
quickly.)

Roughly:
1. rejig the lvm metadata for the new configuration [lvm]
- appends the "whole LV" data to the pool's data
2. Generate metadata for the appended data and append this to the metadata area [dmpd]
3. suspend all the affected devices [lvm]
4. link the already-prepared metadata into the existing metadata [dmpd]
5. resume all the devices (now using the new extended pool)

Alasdair

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

Thread Tools




All times are GMT. The time now is 03:07 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org