[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] Re: [PATCH v2] dm: add topology support



On Wed, Jun 10, 2009 at 06:06:36PM -0400, Martin K. Petersen wrote:
> The default limits should all be set by the block layer when setting up
> the request queue.  So my reason for inquiring was to figure out whether
> check_for_valid_limits() actually makes any difference?
 
I renamed that badly-named function earlier to:
  init_valid_queue_limits()

It should also really be shared with block/.

What's going on is that LVM prepares the new tables it wants to
build up a device stack in advance, then if everything has worked,
makes them all go live.

The validation has to happen during the first phase - backing out
the change to the device stack upon a failure is easier then as
we have not yet reached the commit point of the transaction.
The operation making the new stack live if at all possible must not
fail, because that comes within the commit logic and would make recovery
much trickier.

In dm terms, this means we have two tables - called 'live' and
'inactive'.  The first phase sets up inactive tables on all the stacked
devices involved in the transaction and that is when all the memory
needed is allocated and the validation occurs.  The second phase then
makes the inactive table live and discards the previously-live table.
The two tables are independent: the old queue limits on the dm device
are discarded and replaced by the newly-calculated ones.

Currently those limits are calculated in phase one, but we should see
about delaying this limit combination code (which should alway succeed)
until phase two (which gives userspace code more freedom in its use of
the interface).

Alasdair


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]