Re: critical kernel panic on 4.2 (or any other version) on hammer volume-del

I see this is a completely unsupported feature I use now. Can anyone
explain will volume-del also work on a non-empty volume if I have enough
space on my HAMMER file system to move data to? For example, will the
following scenario work, if I add a new 1TB volume and delete an old one of
500GB?

2015-08-31 22:10 GMT+03:00 Tomohiro Kusumi <[email protected]>:

> 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.
>
> 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.
>
> 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.
>
> 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
> hmp->volume_to_remove != -1
> similar to the way blockmap allocator checks it while looking for free
> space within a bigblock.
>