<div dir="ltr">On Mon, Aug 12, 2013 at 9:18 AM, John Griffith <span dir="ltr"><<a href="mailto:john.griffith@solidfire.com" target="_blank">john.griffith@solidfire.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><div class="gmail_quote">
On Mon, Aug 12, 2013 at 9:15 AM, Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This would need to happen on the cinder side on creation. I don't think it is safe for nova to be modifying the contents of the volume on attach. That said nova does currently set the serial number on attach (for libvirt at least) so the volume will show up as:<br>



<br>
/dev/disk/by-id/virtio-<uuid><br>
<br>
Although the uuid gets truncated.<br>
<br>
Vish</blockquote></div></div></div></div></div></blockquote><div><br></div><div>I missed this in my first passthrough. Thanks for pointing that out.</div><div><br></div><div>We still like the idea of creating the filesystem (to make block storage truly self-service for developers), but we might be able to work around that. It seems that my initial feeling that this would be dealt with in Cinder was correct, though.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div style="font-family:'courier new',monospace">The virtio-<uuid> method Vish described has worked pretty well for me so hopefully that will work for you.  I also don't like the idea of doing a parition/format on attach in compute, seems like an easy path to inadvertently loosing your data.</div>
</div></div></blockquote><div> </div><div>We could track the state of the filesystem somewhere in the Cinder model. Only try to initialize it once.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div style="font-family:'courier new',monospace"></div><div style="font-family:'courier new',monospace">If you still want to look at adding the partition/format functionality to Cinder it's an interesting idea, but to be honest I've discounted it in the past because it just seemed "safer" and more flexible to leave it to the instance rather than trying to cover all of the possible partition schemes and FS types etc.  </div>
</div></div></blockquote></div><br></div><div class="gmail_extra">Oh, we don't want to get super fancy with it. We would probably only support one filesystem type and not partitions. E.g. You request a 120GB volume and you get a 120GB Ext4 FS mountable by label.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">It may potentially not be worth the effort, ultimately. We'll have to continue our discussions internally... particularly since now I know where a useful identifier for the volume is under the dev fs.</div>
</div>