[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [dm-devel] NetBSD libdevmapper port
On Tue, 17 Jun 2008, Adam Hamsik wrote:
-----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 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
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.
Main Index |
Thread Index |