On 12/15/2010 8:49 AM, Ross Walker wrote:
>
>>>
>>> LVM overhead is negligible. It is basically a kernel mapping of virtual memory space into 4MB+ extents across drives.
>>>
>>> It basically has the same overhead as Linux's virtual memory subsystem.
>>
>> Maybe, if memory access time was measured in many milliseconds to move chunk to
>> chunk...
>
> The LVM portion that maps LBAs to LV offsets is completely in memory. When an LV is initially allocated it's extents are contiguous, only after growing it does it become fragmented and those fragments will be large, 4GB here, 4GB there, which should minimize the seek time factor (especially on busy systems).
>
> For VGs containing muliple PVs you can stripe LVs across them to get multiple times the throughput.
>
> The "overhead" that people talk about is the overhead of the memory lookup going from virtual memory LBA to physical disk(s) PBA, which is negligible.
No, the bigger problem is that (a) the mapping table consumes RAM that
would otherwise be available for filesystem buffers - but I suppose in a
64-bit machine you could add more to offset that, and (b) it screws up
any notion that the filesystem has about optimizing head motion by
keeping certain things nearby when the physical layout is remapped. And
if you don't remap into non-contiguous chunks you didn't need it in the
first place.
--
Les Mikesell
lesmikesell at gmail.com