Re: RAID help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Dec 15, 2010, at 10:37 AM, Les Mikesell <lesmikesell@xxxxxxxxx> wrote:

> 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.

Like you mentioned in a 64-bit OS the table is of small consequence and on a 32-bit OS your not likely to be handling extremely large VGs so the table is of little consequence.

As far as file system optimizing head motion, if the space is contiguous on a single drive or mirror then that is not an issue, if the space is striped across multiple PVs then you just give the striping hints to mkfs like a hardware RAID (in fact if the LV is on a hardware RAID PV and not striped in LVM then use the striping hints for the HW RAID).

LVM isn't about re-mapping into non-contiguous regions, it's about volume management, where one can create and expand volumes other then at install time and without modifying the partition tables which brings risk.

If your managing a 3TB volume it's much easier to do so with LVM then gparted.

Snapshotting is anther handy feature for backups, or for creating a recovery point before an upgrade.

-Ross

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux