[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [dm-devel] NetBSD libdevmapper port
-----BEGIN PGP SIGNED MESSAGE-----
On Jun,Friday 13 2008, at 6:51 PM, Mikulas Patocka wrote:
If you are rewriting it --- have you somehow thought about avoiding
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----
Main Index |
Thread Index |