Re: block allocators and LVMs

En réponse à Joe Thornber <[e-mail]>: 
 
> 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).