Messages in this thread | | | Date | Fri, 18 Oct 2002 16:03:37 +0100 | Subject | Re: block allocators and LVMs | From | Joe Thornber <> |
| |
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/
| |