On 11/19/2010 11:17 AM, Bryn M. Reeves wrote: > On 11/18/2010 06:23 PM, Patrick Dupre wrote: >> Hello, >> >> How should I choice the extent size when I create a volume group ? >> How can I avoid unallocated size in a volume goup, even when >> I cannot allocated more size ? >> >> thank. > > vgcreate --physicalextentsize PhysicalExtentSize[bBsSkKmMgGtTpPeE] > > The units behave as for other LVM2 commands. See the man page for more details. > > I'm not sure I understand your question about unallocated size? Can you explain > the problem a bit more? Ah, I think I misread your question. You wanted to know how to choose the best size not how to tell the tool what size to use and I assume this relates to your question about unallocated space. In LVM1 the choice of extent size also governed the maximum size of an LV since there was a hard limit on the number of extents per volume (65534). This restriction no longer applies in LVM2 (there are limits but they are high enough not to be a practical concern today) so the choice of extent size comes down to a tradeoff between more flexible allocations and less wasted space (smaller extents) and more efficient tool operation (larger extents). For e.g. with any given extent size there may be up to just under the extent size of wasted space at the end of a device (depending on how the extent size divides into the device size). A 1G extent has the potential for a lot more wasted space than a 4M extent but means that we have 256 times more extents to deal with for the same volume of space. Whether this is a concern depends on your specific situation. There is no impact from extent size on I/O performance for LVM2 devices but the fact that the tools must process longer lists for smaller extents does have some effect on performance. Virtually all of my VGs use the default 4M. I've occasionally created VGs with larger extents when using larger storage (external arrays) where I expect to have multiple-TB VGs but to be honest I have never seen really noticable performance degradation from using a smaller extent size (you'll notice the effect of having huge numbers of PVs a lot more!) Regards, Bryn. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
