<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 22, 2015 at 6:17 PM, John Griffith <span dir="ltr"><<a href="mailto:john.griffith8@gmail.com" target="_blank">john.griffith8@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Tue, Sep 22, 2015 at 5:48 PM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@outlook.com" target="_blank">harlowja@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A present:<br>
<br>
>>> import contextlib<br>
>>> import os<br>
>>><br>
>>> @contextlib.contextmanager<br>
... def synced_file(path, mode='wb'):<br>
...   with open(path, mode) as fh:<br>
...      yield fh<br>
...      os.fdatasync(fh.fileno())<br>
...<br>
>>> with synced_file("/tmp/b.txt") as fh:<br>
...    fh.write("b")<br>
...<br>
<br>
Have fun :-P<br>
<br>
-Josh<div><div><br>
<br>
Robert Collins wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 23 September 2015 at 09:52, Chris Friesen<br>
<<a href="mailto:chris.friesen@windriver.com" target="_blank">chris.friesen@windriver.com</a>>  wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I recently had an issue with one file out of a dozen or so in<br>
"/opt/cgcs/cinder/data/volumes/" being present but of size zero.  I'm<br>
running stable/kilo if it makes a difference.<br>
<br>
Looking at the code in volume.targets.tgt.TgtAdm.create_iscsi_target(), I'm<br>
wondering if we should do a fsync() before the close().  The way it stands<br>
now, it seems like it might be possible to write the file, start making use<br>
of it, and then take a power outage before it actually gets written to<br>
persistent storage.  When we come back up we could have an instance<br>
expecting to make use of it, but no target information in the on-disk copy<br>
of the file.<br>
</blockquote>
<br>
If its being kept in sync with DB records, and won't self-heal from<br>
this situation, then yes. e.g. if the overall workflow is something<br>
like<br>
<br>
receive RPC request<br>
do some work, including writing the file<br>
reply to the RPC with 'ok'<br>
->  gets written to the DB and the state recorded as ACTIVE or whatever..<br>
<br>
then yes, we need to behave as though its active even if the machine<br>
is power cycled robustly.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Even then, fsync() explicitly says that it doesn't ensure that the directory<br>
changes have reached disk...for that another explicit fsync() on the file<br>
descriptor for the directory is needed.<br>
So I think for robustness we'd want to add<br>
<br>
f.flush()<br>
os.fsync(f.fileno())<br>
</blockquote>
<br>
fdatasync would be better - we don't care about the metadata.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
between the existing f.write() and f.close(), and then add something like:<br>
<br>
f = open(volumes_dir, 'w+')<br>
os.fsync(f.fileno())<br>
f.close()<br>
</blockquote>
<br>
Yup, but again - fdatasync here I believe.<br>
<br>
-Rob<br>
<br>
<br>
</blockquote>
<br></div></div><div><div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div></div></div><div style="font-family:monospace,monospace">​That target file pretty much "is" the persistence record, the db entry is the iqn and provider info only.  I think that adding the fdatasync isn't a bad idea at all.  At the very least it doesn't hurt.  Power losses on attach I would expect to be problematic regardless.</div></div></div></blockquote><div> </div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​Let me clarify the statement above, if you loose power to the node in the middle of an attach process and the file wasn't written properly you're most likely 'stuck' and will have to detach (which deletes the file) or it will be in an error state and rebuild the file when you try the attach again anyway IIRC, it's been a while since we've mucked with that code (thank goodness)!!</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​</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:monospace,monospace"><br></div><div style="font-family:monospace,monospace">Keep in mind that file is built as part of the attach process stemming from initialize-connection.</div><span class="HOEnZb"><font color="#888888"><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">John</div><br></font></span></div></div>
</blockquote></div><br></div></div>