On Fri, Feb 01, 2002 at 05:12:51AM -0500, Arjan van de Ven wrote: > On Thu, Jan 31, 2002 at 01:09:13PM +0000, Joe Thornber wrote: > > > > Now our hero decides to PV move PV2 to PV4: > > > > 1. Suspend our LV (254:3), this starts queueing all io, and flushes > > all pending io. > > But "flushes all pending io" is *far* from trivial. there's no current > kernel functionality for this, so you'll have to do "weird shit" that will > break easy and often. Here's the weird shit. If you can see how to break it, I'd like to know. Whenever the dm driver maps a buffer_head, I increment a 'pending' counter for that device, and hook the bh->b_end_io, bh->b_private function so that this counter is decremented when the io completes. This doesn't work with ext3 on 2.4 kernels since ext3 believes the b_private pointer is for general filesystem use rather than just b_end_io, however Stephen Tweedie and I have been discussing ways to get round this. On 2.5 this works fine since the bio->bi_private isn't abused in this way. > Also "suspending" is rather dangerous because it can deadlock the machine > (think about the VM needing to write back dirty data on this LV in order to > make memory available for your move)... You are correct, this is the main flaw IMO with the LVM1 version of pvmove (which was userland with locking on a per extent basis). However for LVM2 the device will only be suspended while a table is loaded, *not* while the move takes place. I will however allocate the struct deferred_io objects from a mempool in 2.5. - Joe _______________________________________________ linux-lvm mailing list linux-lvm@sistina.com http://lists.sistina.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html