<div dir="ltr">On Tue, Aug 13, 2013 at 1:37 PM, Caitlin Bestler <span dir="ltr"><<a href="mailto:caitlin.bestler@nexenta.com" target="_blank">caitlin.bestler@nexenta.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 class="im"><span style="color:rgb(34,34,34)">I'm not following something here. What is the point at dictating a specific FS format when the compute node will be the one applying</span><br>
</div>
the interpretation?<br></blockquote><div><br></div><div>This is the rabbithole that made me start to re-think our approach.</div><div><br></div><div>Our goal is to make it so that developers can self-service provision additional storage for themselves, grow filesystems, etc without having to ... well... know how. There are so many approaches to this (within the Openstack community) that we thought "why not just make this something that Cinder can do?"</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Isn't a 120 GB volume which the VM will interpret as an EXT4 FS just<br>
a 120 GB volume that has a *hint* attached to it?<br></blockquote><div><br></div><div>Yes, in the same sense that a 120 GB volume is just a starting point on a disk with a hint attached to it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

And would there be any reason to constrain in advance the set of hints<br>
that could be offered?</blockquote><div><br></div><div>Simplicity.</div><div><br></div><div>I think that what would make this idea tractable would be to abstract away the filesystem-level stuff into an abstract factory that Cinder would use. Each FS type would implement the factory accordingly and register itself somehow with Cinder. So Cinder operators would have a range of choices for making filesystems available to users.</div>
<div><br></div><div>Of course, that's anything but simple, right?</div><div><br></div><div>What we really want (and are comfortable working with) is predictability and consistency.</div><div><br></div><div>Currently, if I specify a device name via nova volume-attach, we can end up in a state where our metadata regarding the attachment is incorrect. E.g. a device is attached as /dev/vdb, but I specified /dev/vdc and the attachment's 'device' parameter says /dev/vdc.</div>
<div><br></div><div>We have the alternative of using the truncated /dev/disk/by-id/virtio-<truncated uuid> to find the attached volume, but you cannot guarantee that there will not be a collision in an environment with a sufficient number of volumes.</div>
<div><br></div><div>I'd be personally satisfied if that weren't truncated and would move along. It's something else I'm looking into. </div></div></div></div>