On Fri, Feb 21 2014 at 9:27am -0500, Joe Thornber <thornber@xxxxxxxxxx> wrote: > NACK. > > On Thu, Feb 20, 2014 at 09:56:03PM -0500, Mike Snitzer wrote: > > Before, when a pool is being resized, on resume the pool's mode was > > being immediately set to PM_WRITE and the process_* methods would be set > > to the normal writable operations. These were established before > > pool_resume() was able to actually resize either the metadata or data > > device and resulted in the resize failing. This failure occurred due to > > the thin device calling wake_worker() which kicked do_worker() during > > pool_preresume() -- which caused calls to the writable process_* methods > > to occur during the resize. > > The bug is the worker should not be able to be woken until > pool_preresume has completed. A simple check in wake_worker() should > fix this. > > > Now, the pool is forced to stay in read-only mode if it was already in > > read-only mode. This prevents bouncing the pool's mode and associated > > process_* methods and consistently keeps read-only processing in place > > until the resize(s) complete. To achieve this the pool can now be in a > > PM_READ_ONLY state but the metadata's is !read_only -- so as to allow > > the commit() the follows the resize to take place. Differentiate > > between commit_metadata_superblock() and commit() since different > > negative checks apply (but factor out a common __commit that each > > calls). > > Too complicated. You may think it complicated, and yeah it isn't dead simple, but it unlocks the nuanced state that is needed to allow for fixing data space exhaustion that still allows for prepared_mappings to complete -- even though the pool is in read-only mode. So patch 7 depends on this patch. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
