<div dir="ltr"><div>Well, I'm amazed the volume-add/volume-del work at all.  It was coded way back in 2009 by Michael Neumann (I think), but only a few people ever used it so the feature has never seen the same sort of use or load that other features have seen.<br><br></div><div>It would be pretty cool if you could get the volume add/del stuff working reliably.<br><br></div><div>If you post the backtrace I might have some ideas on what the timing issue between the flusher and the volume-del code could be.<br></div><div><br></div>-Matt<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 31, 2015 at 12:10 PM, Tomohiro Kusumi <span dir="ltr"><<a href="mailto:kusumi.tomohiro@gmail.com" target="_blank">kusumi.tomohiro@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>There is a critical kernel panic issue while running hammer volume-del. I've seen this happens not only on master, but also 4.2.4 release kernel (which was before I started to touch hammer volume-add|del ioctl code) and probably older kernels too from the way it works.<br></div><div><br></div><div>This seems to be a timing issue, race between ioctl called by a volume-del process and the flusher kernel thread. It's relatively easy to reproduce in my environment with >=4 volumes but never with 2 or 3 volumes. The first one or two volumes need to be filled up and make reblock run before unloading the volume in order to reproduce this.</div><div><br></div><div>In the worst case, a volume gets removed and volume header gets erased as usual, but kernel could panic before volume count of remaining volumes get updated (decremented). This results in inconsistency between volume count and # of valid volumes, and the filesystem will no longer be mountable unless directly edit the volume header of block devices.</div><div><br></div><div>I haven't fixed this yet, nor is it obvious, but it seems the flusher kernel thread needs to be aware of ongoing volume-del by checking if</div><div>hmp->volume_to_remove != -1</div><div>similar to the way blockmap allocator checks it while looking for free space within a bigblock.</div></div>
</blockquote></div><br></div>