<br><br><div class="gmail_quote">On Fri, Nov 2, 2012 at 5:55 PM, Christoph Hellwig <span dir="ltr"><<a href="mailto:hch@infradead.org" target="_blank">hch@infradead.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Thu, Nov 01, 2012 at 12:03:10AM +0800, Rongze Zhu wrote:<br>
> 1. You are right, it just requires basic Posix filesystems APIs + Linux<br>
> xattrs.<br>
> But you know that naming is very hard, so I temporarily name it to 'ext4'.<br>
> In<br>
> the future, I will give it a new name.<br>
<br>
</div>I'd say just stick to localfs or similar as that is most descriptive.<br>
<div><br>
> 2. I am not familiar with md5 and sha1, but md5 is only used for checksum,<br>
> why<br>
> it is a bit dangerous? I'm confused :)<br>
<br>
</div>MD5 is an old hashing algorithm for which it's fairly easy to find hash<br>
collisions. I actually misread the code and thought you'd use the hash<br>
for content addressing, in which case this would be a real issue. If<br>
it's just a checksum against corruption it's not bad, but I'd still<br>
recommend using a better hash algorithm these days.<br>
<div><br>
> 3. If qcow3 format is comming, I also need to implement qcow3 python<br>
> library.<br>
<br>
</div>"Qcow3" is a set of extensions to the qcow2 format. The format is still<br>
handled by the same driver, just the version field in the header is<br>
bumped to 3. If I'm reading the python code in your branch correctly<br>
there currently is no support for that, but no check to reject it<br>
either.<br></blockquote><div><br>+1, I will check version field in my code. Thanks your suggestion.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> I only read snapshot data and metadata from image, qemu concurrent I/O will<br>
> not<br>
> modify snapshot data and metadata, so it is consistency.<br>
<br>
</div>I'd like a bit more documentation an asserts that this is really the<br>
case.<br>
<br>
</blockquote><div><br>I had read the qemu-kvm code, it is really the case:)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In addition I have another question, although that might be more towards<br>
the nova gurus on the list: What guarantees no I/O is pending when<br>
the create_snapshot method is called? Just like in a driver I'm writing<br>
right now you call qem-u-img snapshot from the create_snapshot method,<br>
and I'm again worried about qemu accessing it concurrently. The same<br>
issue also applied to the delete_snapshot method. I've been trying to<br>
dig into this, but the API documentation for cinder seems severly<br>
lackingunfortunately.<br>
<div><br></div></blockquote><div> <br>I had read qemu-kvmq code, emu-kvm have a io-thread for handling timers, processing I/O, and responding to monitor commands. When qemu-kvm handle monitor command, io-thread will call qemu_mutex_lock_iothread()
to lock the emulated devices, so vcpu threads cannot access the emulated devices. In a word, we use qemu_mutex_lock_iothread()/qemu_mutex_unlock_iothread() to
protect the race to access the emulated dev launched by vcpu threads & iothread. You can get more detail from h<a href="ttp://web.archiveorange.com/archive/v/1XS1vRhfyKIEzDUVAgUP">ttp://web.archiveorange.com/archive/v/1XS1vRhfyKIEzDUVAgUP</a> and <a href="http://comments.gmane.org/gmane.comp.emulators.qemu/68855">http://comments.gmane.org/gmane.comp.emulators.qemu/68855</a> .<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> 4. I agree with you, it is best that we can export snapshot data and<br>
> metadata from image by monitor command.<br>
<br>
</div>I'd suggest going there, as it means all format specific are hidden<br>
in qemu, this would also allow to support e.g. vhd or vmware images<br>
without changes to your openstack code.<br>
<br>
You already need a qemu patch anyway so I don't think it's a huge issue.<br>
<br>
Thinking about qemu I think your initial provisioning in the<br>
initialize_connection could also be greatly simplified by using the<br>
copy on read support in recent qemu. This uses the qemu backing device<br>
support, but updates the overlay image not only on writes but pages in<br>
data on reads as well and thus gradually moves the data to be local.<br></blockquote><div><br>+1, greatly! Thank your suggestion, I will pay attention on it. :) <br></div></div><br><br clear="all"><br>-- <br><br><span><font color="#888888">Rongze Zhu - 朱荣泽 </font></span><br>
<span><font color="#888888"><span>Twitter: @metaxen<br></span><span style="font-size:13px;font-family:arial,sans-serif">Blog: <a href="http://blog.csdn.net/metaxen" target="_blank">http://blog.csdn.net/metaxen</a><br>
Weibo: </span></font></span><span><font color="#888888"><span style="font-size:13px;font-family:arial,sans-serif"><a href="http://weibo.com/metaxen" target="_blank">http://weibo.com/metaxen</a><br>Website: Try Free OpenStack in <a href="http://stacklab.org" target="_blank">http://www.stacklab.org</a><br>
<br></span></font></span><br>