[lkml]   [2002]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: block allocators and LVMs
En réponse à Joe Thornber <>: 

> 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
extend = dequeue_lowest_user_extend
if extend_in_good_spot

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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:30    [W:0.067 / U:11.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site