On Fri, Nov 07 2014 at 6:16pm -0500, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > > > On Fri, 7 Nov 2014, Mikulas Patocka wrote: > > > For reasons 1 and 2, I wouldn't really deal with "thin" targets at all - > > they may be created or deleted independent on pool status. Instead, we > > should block all active bios inside the pool - the bios are already > > registered in dm_deferred_set or in the prison, so all you need to do is > > to set a flag pool's presuspend method that causes all new bios to be > > queues and the wait until the prison is empty and the counters in > > deferred_set reach zero. > > Here I'm sending a proof-of-concept patch that makes it possible to > prevent bios from coming into the thin pool when the pool is suspended. It > doesn't modify any generic dm code. > > This patch may not be perfect (I don't know all bio paths in dm-thin in > detail, so I may have missed something), but it shows that it is possible > to suspend all bios without modifying the common dm code. I hope Joe > reviewes it and possibly fixes it. > > The patch is for 3.18-rc3, it needs other thin patches, the full patch > series is at > http://people.redhat.com/~mpatocka/patches/kernel/dm-thin-suspend/series.html Happy to consider your solution, thanks for taking the time to work on it. I also revised my dm_internal_{suspend,resume} changes based on your feedback and have published the changes here: https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/log/?h=dm-for-3.19 (rebased so the top ~11 patches are the ones to look at) I'm happy with how this code turned out, but it is certainly a fair amount of code churn in DM core. All said, I'll work with Joe to figure out the best way forward next week. Could easily be that your approach wins out. BTW, have a great break. Mike -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
