<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 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 class="HOEnZb"><div class="h5"><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 class="HOEnZb"><div class="h5">
__________________________________________________________________________<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 class="gmail_default" 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 class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Keep in mind that file is built as part of the attach process stemming from initialize-connection.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">John</div><br></div></div>