Thanks Thomas, You are correct in that we want the flexibility of lvm to grow the disk on to another device (md2 in this case), in the future should it be required.
The other reason being that md3 could be comprised of ssds and md2 spinning disks, in our experience this does give better IO for the lv using the faster disks. In this example md2 might be used temporarily to increase the solr lv until more ssds are added. It's mostly about flexibility still. I am less bothered about point 2 from my original reply, so just changing the order of when lvcreateopts is injected into the lvcreate command would suffice and I don't think it would effect current functionality? Thanks for listening, LukeĀ -------- Original message -------- From: Thomas Neumann Date:21/11/2014 17:12 (GMT+00:00) To: fully automatic installation developers list Subject: Re: lvcreateopts ordering / sizing Hello Luke On Friday 21 November 2014 14:24:27 Luke Alexander wrote: > 1) be able to create an lv using extents from a specific physical device in > the vg > 2) be able to allocate 100% of the extents from that specific device What's the deeper meaning behind this? From just this description there's not much difference compared to using the physical volume directly. The only thing that I can think of is that you may want to grow the solr-lv with some extents from md2 later on. But if that's possible later then why don't you do it right from the start? One other reason could be to make sure the disk I/O-queues for root and mnt are separate from solr - but to be frank I don't even know if LVM really works that way. It may as well be that the actual device I/O is indeed going into different queues, but shares the same queues (and latencies) on the LVM level. bye thomas