[dm-devel] NetBSD libdevmapper port

Mikulas Patocka mpatocka at redhat.com
Mon Jun 16 23:26:24 UTC 2008



On Tue, 17 Jun 2008, Adam Hamsik wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Jun,Friday 13 2008, at 6:51 PM, Mikulas Patocka wrote:
>
>> Hi
>> 
>> If you are rewriting it --- have you somehow thought about avoiding 
>> suspend?
>
> device suspend/resume are unsupported for now. I was not sure what these 
> commands should really do.
> Because GPL/BSD licensing issues I haven't look at linux code.
>
>> 
>> 
>> A big source of problems in Linux is, that when you suspend a device, you 
>> can do only a limited set of calls --- basically, you must avoid anything 
>> that could possibly wait for I/O or allocate memory --- or you might end up 
>> waiting for the suspended device and deadlock. And I know still about 3 
>> places in kernel that have this error possibility.
>
> ok but why I should want to do something like suspending of device ? to 
> avoid IO operations when I'm changing device table

Yes, exactly that. For example if you are about to move a logical volume 
somewhere else, lvm replaces it with dm-raid1 target that does the 
copying. If there were old IOs for the old linear target flying around 
while dm-raid1 copies the data, there would be data corruption.

It also updates on-disk metadata while it's suspended. I'm not sure if 
this is really needed to update them at this point. Maybe at some cases it 
is.

> or what problem are device suspend/resume want to solve. If this 
> is problem I can use one mutex
> shared between dm_dev_suspend/resume_ioctl call and dmstrategy(this routine 
> does IO) so I can avoid IO's when device is suspended.

The problem is that when you lock this mutex, you must avoid any memory 
allocation (because it may submit write IO and wait for it). And it's very 
hard to do it if you return to userspace.

Mikulas




More information about the dm-devel mailing list