<html><head></head><body>@JAB<br>
<br>
Same here passing the same LVM LV's through to multiple KVM instances works a treat for testing.<br>
<br>
-- Lauz<br><br><div class="gmail_quote">On 13 June 2016 22:05:20 EEST, Jonathan Buzzard <jonathan@buzzard.me.uk> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 13/06/16 18:53, Marc A Kaplan wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> How do you set the size of a ZFS file that is simulating a GPFS disk?<br /> How do "tell" GPFS about that?<br /><br /> How efficient is this layering, compared to just giving GPFS direct<br /> access to the same kind of LUNs that ZFS is using?<br /><br /> Hmmm... to partially answer my question, I do something similar, but<br /> strictly for testing non-performance critical GPFS functions.<br /> On any file system one can:<br /><br /> dd if=/dev/zero of=/fakedisks/d3 count=1 bs=1M seek=3000 # create a<br /> fake 3GB disk for GPFS<br /><br /> Then use a GPFS nsd configuration record like this:<br /><br /> %nsd: nsd=d3 device=/fakedisks/d3 usage=dataOnly pool=xtra<br /> servers=bog-xxx<br /><br /> Which starts out as sparse and the filesystem will dynamically "grow" as<br /> GPFS writes to
it...<br /><br /> But I have no idea how well this will work for a critical "production"<br /> system...</blockquote><br /><br />For "testing" purposes I just create a logical volume and map it through <br />to my bunch of GPFS KVM instances as a disk. Works a treat and SSD's are <br />silly money these days so for testing performance is just fine. There <br />was a 960GB SanDisk on offer for 160GBP last month.<br /><br />JAB.<br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>