gjournal is broken in handling its flush_queue. If we have 10 bio's
in the flush_queue:

1 2 3 4 5 6 7 8 9 10

and another 10 bio's go into the flush queue after only the first five
bio's are removed from the flush queue, the queue should look like:

6 7 8 9 10 11 12 13 14 15 16 17 18 19 20,

but because of the bug we end up with

6 11 12 13 14  15 16 17 18 19 20 7 8 9 10.

So the sequence of the bio's is damaged in the flush queue (and
therefore in the journal on disk !). This error can be triggered by
ffs_snapshot() when a block is read with readblock() and gjournal finds
this block in the broken flush queue before it goes to the correct
active queue.

The fix is to place all new blocks at the end of the queue.

Submitted by: Dr. Andreas Longwitz <longwitz@incore.de>
Discussed with: kib
MFC after: 1 week