[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.022 / U:19.832 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site