On Thursday 05 June 2003 04:39, Joe Thornber wrote:
> Here's the header file for the the proposed new ioctl interface for
> dm. We've tried to change as little as possible to minimise code
> changes in LVM2 and EVMS.
>
> The changes address the following problems:
>
> o) Alignment mistakes in the ioctl structures
>
> o) Provide a way for the userland tools to back out of a series of
> table updates without having to reload the orginal tables (remember
> that an LV is often composed of a stack of 2 or more dm devices).
This should be very helpful for error recovery when setting up snapshots.
> o) Pre-loading of a new table may now occur without suspending the
> device. (Table loading can potentially allocate a lot of memory,
> eg. mirror buffers).
Cool.
> o) Minimise the amount of time that a device is suspended. eg. if a
> simple linear mapping is being extended, there is no longer a need to
> call the suspend ioctl in between the table load and the resume.
> Instead the resume (which swaps in the new table), will do the right
> thing.
Also very nice. This ought to elimate the possibility of deadlock due to
suspending the device from user-space. I really like this solution!
I'll bring up a couple of the points Alasdair and I were discussing on irc
yesterday:
1) Snapshots. Currently, the snapshot module, when it constructs a new table,
reads the header and existing exception tables from disk to determine the
initial state of the snapshot. With this new scheme, this setup really
shouldn't happen until the device is resumed (if it is done when the
"inactive" table is created, an existing "active" table could change the
on-disk information before the tables are switched). This kind of implies a
new entry-point into the target module will be required.
2) Removing suspended devices. The current code (2.5.70) does not allow a
suspended device to be removed/unlinked from the ioctl interface, since
removing it would leave you with no way to resume it (and hence flush any
pending I/Os). Alasdair mentioned a couple of new ideas. One would be to
reload the device with an error-map and force it to resume, thus erroring any
pending I/Os and allowing the device to be removed. This seems a bit
heavy-handed. Another idea was to allow removing suspended-devices which
aren't open. But that seems a bit racy. The current code doesn't seem to
coordinate removal of a device from the interface with opening of the device.
So you could potentially be opening the device at the same time you are
removing it from the interface. Personally, I think the current behavior is
fine. User-space can use the new list-devices command along with the
dev-status command to determine if a device should be resumed before trying
to remove it.
Any thoughts?
-- Kevin Corry kevcorry@us.ibm.com http://evms.sourceforge.net/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 07 2003 - 22:00:27 EST