[dm-devel] NetBSD libdevmapper port

[Adam Hamsik]

-----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 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.

>
>
> A Linux LVM does something like: suspend old table, write to disk  
> with direct i/o, resume new table. I'd suggest that you invent some  
> method how to batch these operations into single syscall --- or you  
> run into a several years of deadlock problems on NetBSD ---  
> basically, on Linux, we have to preallocate a stack and heap (so  
> that running LVM process won't cause a page fault --- the question  
> --- how to do it portably on all NetBSD architectures?), mlock the  
> process, make sure that we don't open files or write anything to  
> terminal while suspended, make sure that the ioctl syscall doesn't  
> allocate anything (currently false, it won't deadlock but it could  
> randomly fail), make sure that O_DIRECT write syscall doesn't  
> allocate anything or wait for other I/O (currently it false, there  
> is a deadlock possibility) ... etc.
>
> --- if you port lvm2 as it is, you'll have to audit (and maybe  
> rewrite) many parts of NetBSD kernel for not waiting for I/O. If you  
> do it badly, you'll get deadlocks.

I want definitely avoid such massive changes to our kernel.

>
>
> This suspend thing was a big misdesign and if you are writing it  
> from scratch, try to avoid it.

Regards

Adam.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFIVuNElIxPgX3Go0MRAvoaAJ9TC+dcYmp9S7yv/0un4YcMUE+AwwCeP1G0
C5o2j8D/+heQATR8eewYd34=
=dmZO
-----END PGP SIGNATURE-----