<div dir="ltr">On Mon, Aug 12, 2013 at 10:26 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.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">Like others, I am a little dubious about adding a filesystem to these<br>
disks for a number of reasons. It feels like a violation of "its just<br>
a bunch of bits".<br></blockquote><div><br></div><div>I actually think that it's a valid concern. I've been trying to come up with a stable, reasonable solution ever since I sent the original e-mail. :)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Have you considered putting a GPT on it instead?</blockquote><div><br></div><div>We have.</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With a GPT you have a UUID for the disk which you can communicate to the<br>
host via metadata service. With that you can instruct gdisk to partition<br>
the right disk programattically and create the filesystem with native<br>
in-instance tools.<br></blockquote><div><br></div><div>I'm not sure that this is any different from:</div><div>- Examine current disk devices</div><div>- Attach volume</div><div>- Examine current disk devices</div><div>
- Get device ID from diff</div><div>- Do something</div><div><br></div><div>That seems to be pretty much the pattern that everyone has used to solve this problem. What this says to me is that this is a common problem, and perhaps it is a failing of Cinder to simply provide this functionality. Even if it doesn't bother creating a filesystem, it seems like it should make a best effort to ensure that the volume is identifiable within the instance after attachment--as opposed to the current implementation of "throw hands up in the air and have the state lie about the device name of the volume". Currently we have metadata that says it's /dev/vdc, when in reality it's /dev/vdb. That's a bug, imo.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is pure meta-data, and defines a lot less than a filesystem, so it<br>
feels like a bigger win for the general purpose case of volumes.  It will<br>
work for any OS that supports GPT, which is likely _every_ modern PC OS.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Honestly, the only reason we were considering putting the filesystem on it was to use tune2fs to put a label (specifically the volume ID) directly attached to the filesystem. If we can manage to store the state of the volume attachment in the metadata service and ensure the validity of that data, then we will go that route. We simply haven't been able to do that without some kind of wonkiness.</div>
</div></div></div>