Messages in this thread | | | From | christophe varoqui <> | Subject | Re: block allocators and LVMs | Date | Fri, 18 Oct 2002 17:51:47 +0200 |
| |
On Friday 18 October 2002 17:03, you wrote: > 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. > 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.
cva - 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/
| |