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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
