lkml.org 
[lkml]   [2002]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: block allocators and LVMs
From
On Fri, Oct 18, 2002 at 03:04:24PM +0200, christophe.varoqui@free.fr wrote:
> I realize I didn't pick the right words (from my poor English
> dictionnary) : I meant an extend remapper rather than a block remapper.

extent 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

What you describe could be very beneficial, especially if you start
striping the high bandwidth areas. However in no way could this be
described as 'online FS defragmentation'.

- Joe
-
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/

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