En réponse à Joe Thornber <joe@fib011235813.fsnet.co.uk>:
> Christophe,
> > the role of intelligent block allocators and/or online FS
> > defragmentation could be replaced by a block remapper in the
> > LVM subsystem.
>
> Crazy idea :)
>
> I think this is best left to the fs to handle, mainly because the
> blocks that the fs deals with are so small. You would end up with
> *huge* remapping tables. Also you would need to spend a lot of time
> collecting the information neccessary calculate the remapping, to do
> it properly you'd need to record an ordering of data acccesses not
> just io counts (ie. so you could build a Markov chain).
>
I realize I didn't pick the right words (from my poor English
dictionnary) : I meant an extend remapper rather than a block remapper.
As far as I can see, this task can be done entirely from userland :
o per-extend IO counters exported from kernel-space can be turned into
a list of extends sorted by activity
o lvdisplay-like tool gives the mapping extend<->physical blocks
o a scheduled job in user-space should be able to massage this info to
decide where to move low-access-rate-extends to the border of the
platter and pack high-access-rate-extends together ... all in one run
that can be scheduled at low activity period (cron defrag way)
The algorithm could be something along the line of :
while top_user_queue_not_empty
do
extend = dequeue_lowest_user_extend
if extend_in_good_spot
then
move_extend_to_corner_destination
find_highest_user_extend_in_bad_spot
move_this_extend_to_freed_good_spot
fi
done
This sort of extend reordering is done in some big Storage Arrays like
StorageWorks EVA110 (as far as I know : they are very secretive on the
subject).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:41 EST