<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body >Thanks Thomas,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Thanks for listening,</div><div>Luke </div><br><br><div style="font-size:100%;text-align:left;color:#000000"><div>-------- Original message --------</div><div>From: Thomas Neumann <blacky+fai@fluffbunny.de> </blacky+fai@fluffbunny.de></div><div>Date:21/11/2014 17:12 (GMT+00:00) </div><div>To: fully automatic installation developers list <linux-fai-devel@uni-koeln.de> </linux-fai-devel@uni-koeln.de></div><div>Subject: Re: lvcreateopts ordering / sizing </div><div><br></div></div>Hello Luke<br><br>On Friday 21 November 2014 14:24:27 Luke Alexander wrote:<br>> 1) be able to create an lv using extents from a specific physical device in<br>> the vg <br>> 2) be able to allocate 100% of the extents from that specific device<br><br>What's the deeper meaning behind this? From just this description there's not <br>much difference compared to using the physical volume directly. The only thing <br>that I can think of is that you may want to grow the solr-lv with some extents <br>from md2 later on. But if that's possible later then why don't you do it right <br>from the start?<br><br>One other reason could be to make sure the disk I/O-queues for root and mnt <br>are separate from solr - but to be frank I don't even know if LVM really works <br>that way. It may as well be that the actual device I/O is indeed going into <br>different queues, but shares the same queues (and latencies) on the LVM level. <br><br>bye<br>thomas<br><br><br><br><br></body>