[lkml]   [2002]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: block allocators and LVMs
On Friday 18 October 2002 17:03, you wrote:
> On Fri, Oct 18, 2002 at 03:04:24PM +0200, 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.
oops, first desillusion :)

> 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'.
I realize the whole concept is different, but could extent remapping alleviate
the need of an *intelligent* FS block allocator, as it ensure the best
statistical-average IO perfs.

I can even imagine an *intelligent* FS block allocator being counter
productive in the case of a heavily fragmented LV (extends out-of-order ...)
because, after all, block allocator seem to take for granted that the device
is linearly mapped over physical.

This whole point fade into mud if the block group object of an extN FS is
mapped over an LVM extent. But even in this case the *simple* allocator would
be best in combination with an extent remapper.

I don't pretend an extent remapper can replace the FS block allocator, but
only *complex* block allocators ... and particularitly those that make the
false assomption that underlying block device is made of linearly and
consecutive physical blocks.

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.039 / U:1.116 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site