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 09-19-2011, 04:59 PM
Mikulas Patocka
 
Default Thin provisioning bug in interface

The current thin interface works in the following way:

* you create a pool target and pass it two devices, one for metadata and
the other for data

* you create a thin target and pass it a pool device and thin device id

Now the problem:

if you destroy the pool target (reload it with empty table or something
like that) --- the pool structure can't be freed from memory (because a
thin device is open) and it is still active. The problem: the data and
metadata devices are closed. You can't keep them open because "dm_dev" is
bound to a specific dm table and is force-closed when the table is
destroyed.

I thought about fixing it, but concluded that this interface is
fundamentally broken and there is no easy way to do the fix.

There is an unfixable flaw in thin provisioning interface. Something like
"dmsetup remove_all" can trigger it.

I think the interface should be changed in such a way that "thin" target
receives metadata and data devices as its parameters and looks up "pool"
target using these parameters. If we change it this way, the "thin" target
would keep "data" and "metadata" devices open, so if someone destroys the
pool target, the devices would still be accessible and there would be no
risk of crash becuase of using freed kernel structures.

I thin Joe said that Alasdair wanted to have current interface ("thin"
target opens "pool"), but it suffers from an unfixable bug. So Alasdair,
maybe you should change your mind? Or provide some explanation how this
scenario should be fixed?

Mikulas

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 09-19-2011, 05:11 PM
Alasdair G Kergon
 
Default Thin provisioning bug in interface

On Mon, Sep 19, 2011 at 12:59:42PM -0400, Mikulas Patocka wrote:
> if you destroy the pool target (reload it with empty table or something
> like that) --- the pool structure can't be freed from memory (because a
> thin device is open) and it is still active.

You shouldn't be able to destroy the pool target while it is in use.
(When I last looked at it a few weeks ago, I thought the target line
parameters were OK, but just that we'd not fixed every possible usage
sequence/handover yet.)

Alasdair

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 09-19-2011, 07:42 PM
Mikulas Patocka
 
Default Thin provisioning bug in interface

On Mon, 19 Sep 2011, Alasdair G Kergon wrote:

> On Mon, Sep 19, 2011 at 12:59:42PM -0400, Mikulas Patocka wrote:
> > if you destroy the pool target (reload it with empty table or something
> > like that) --- the pool structure can't be freed from memory (because a
> > thin device is open) and it is still active.
>
> You shouldn't be able to destroy the pool target while it is in use.
> (When I last looked at it a few weeks ago, I thought the target line
> parameters were OK, but just that we'd not fixed every possible usage
> sequence/handover yet.)

I am just concerned that this is bloating dm core with more code.
dm-get-md and singleton is already a bloat (it exposes something that
wasn't expected to be exposed to the targets) and now you need to add more
bloat to prevent a cresh when the user reloads 'pool' table without pool
target.

If you designed it just like the old snapshots, there would be no need for
any dm core change.

Mikulas

> 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 11:21 AM.

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