The online repacker is the best technical fix for these problems. Tight
packing is generally more damaged in its layout by small changes than
loose packing, and V4 is the ultimate tight packer. It is not clear to
me that making V4 pack more loosely is necessarily a good idea. These
phases disturb the original packing at flush time, and the other phases
don't. One solution to try is packing less tightly. Maybe once every
megabyte skip forward 1 megabyte, and once every 64 megabytes skip to a
random disk location, when allocating large new atoms. I think I prefer
using a repacker, but we should try it and see. The other solutions of
the previous email should also help a lot. The issues of layout in this
are similar to the ones improved by the fibration plugin.
I remember talking with not just you but zam about how we could fix it,
and there was too much in the queue of work, and everyone was
complaining to me that we should be debugging not optimizing, and you
were the only one who thought it was a big deal. I guess you still
think it is a big issue and I still think things are good enough to use
without it. I still think Zam understood the issues better than you did
(allocation is his code not yours).
There are some layout optimizations that a repacker can do best. Still,
there are some rough spots in the current allocation policy, and we
should look at it.
Probably you will have reason to howl if we setup a benchmark which
disturbs things with these phases, runs the repacker (I hope to have one
in 6 months), and then measures our read performance compared to other
filesystems without a repacker....;-)
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
