<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Josef,<br>
<br>
I installed the patch and it shows that fsync result in calling
sync(). Actually I used fsync(0).<br>
<br>
[init -> test-libc_vfs] Trying sync()<br>
[init -> test-libc_vfs] virtual int
Libc::Vfs_plugin::fsync(Libc::File_descriptor*): <br>
[init -> test-libc_vfs] virtual void
Vfs::Dir_file_system::sync(): <br>
[init -> test-libc_vfs] virtual void
Vfs::Dir_file_system::sync(): <br>
[init -> test-libc_vfs] Virtual sync()
<---------------------------- this my trace in
File_system::sync()<br>
[init -> test-libc_vfs] virtual void Vfs::Fs_file_system::sync():
<br>
[init -> rump_fs] virtual void
File_system::Session_component::sync(): <br>
[init -> test-libc_vfs] sync() done<br>
[init -> test-libc_vfs] test finished<br>
[init] virtual void Genode::Child_policy::exit(int): child
"test-libc_vfs" exited with exit value 0<br>
<br>
I have no explanation for the invocation of virtual void
File_system::sync(), which is where my trace comes from. It could
well be my C++ ignorance.<br>
<br>
In addition to the PWRN macro I placed between the braces, I also
modified the run script to not delete ext2.raw. After the first make
run/rump_ext2, I reran the actual run part with qemu manually.<br>
So if sync() was successfully executed in the first run, the second
run should find a clean file system.<br>
Which is not the case:<br>
<br>
[init -> rump_fs] Backend::Backend(): Backend blk_size 512<br>
[init -> rump_fs] rump: /genode: file system not clean; please
fsck(8)<br>
[init -> test-libc_vfs] calling mkdir(dir_name, 0777)
dir_name=testdir<br>
[init -> test-libc_vfs] mkdir(dir_name, 0777) failed, ret=-1,
errno=28<br>
[init] virtual void Genode::Child_policy::exit(int): child
"test-libc_vfs" exited with exit value -1<br>
<br>
I have to assume that sync() does not reset the not-yet-synced flag
in the superblock, which surprises me. But that would be a rump_fs
internal issue.<br>
<br>
In the Unix/Linux world one normally does not issue a sync() call at
the end of a program (unless<br>
one has paranoia streaks), ideally, one should not be aware of
sync(). So I was looking for a more logical place to have this done
automatically.<br>
<br>
Originally I tried to to solve the lack of an explicit sync call by
placing the sync() in the <br>
destructor of the System_component class. But as far as I can see,
this destructor is never<br>
called. Is there a graceful shutdown process in Nova ? Or, to be
more specific, is rump_fs signaled<br>
that Nova is being shutdown ? <br>
<br>
What does this mean for Nova applications ? Must they organize save
shutdown of a file system ?<br>
How would they do that ?<br>
<br>
Regards, Adrian<br>
<br>
<br>
<div class="moz-cite-prefix">Am 03.02.2015 um 19:13 schrieb Josef
Söntgen:<br>
</div>
<blockquote cite="mid:20150203181341.GA27307@...296..."
type="cite">
<pre wrap="">Hello Adrian,
* a3an <a class="moz-txt-link-rfc2396E" href="mailto:a3an@...294..."><a3an@...294...></a> [2015-01-30 10:56:45 +0100]:
</pre>
<blockquote type="cite">
<pre wrap="">I've got some new indications.
I used the fsync() call to see how that worked out.
It did not work either. By plowing through the vfs header files, I noticed
that File_system contains a virtual function called sync() followed by
{}, and
some comments that only Fs_file_system needs sync.
I placed a PWRN macro call with a msg within the braces and run the test
test again.
The msg appeared on the console.
</pre>
</blockquote>
<pre wrap="">I added debug messages to the code (see the patch file) to trace the
fsync() call and it actually calls the sync() method of rump_fs in the
end:
[init -> test-libc_vfs] open(file_name, O_CREAT | O_WRONLY) succeeded
[init -> test-libc_vfs] calling fsync(fd)
[init -> test-libc_vfs] virtual int Libc::Vfs_plugin::fsync(Libc::File_descriptor*):
[init -> test-libc_vfs] virtual void Vfs::Dir_file_system::sync():
[init -> test-libc_vfs] virtual void Vfs::Dir_file_system::sync():
[init -> test-libc_vfs] virtual void Vfs::Fs_file_system::sync():
[init -> rump_fs] virtual void File_system::Session_component::sync():
[init -> test-libc_vfs] fsync(fd) succeeded
</pre>
<blockquote type="cite">
<pre wrap="">It means there is no overriding implementation for sync(), presumably in
Fs_file_system.
I assume rump_fs has been used in read mode only.
</pre>
</blockquote>
<pre wrap="">We use rump_fs with Ext2 r/w on a regular basis and it worked fine so
far. Since Ext2 does not support any journaling we call sync [1] once
a second to mitigate problems resulting from a potential power loss. I
admit that this is not the best solution to tackle this issue, however
it has to suffice for now. There are plans to port the Ext4 driver from
Linux but there is no concrete schedule, though.
Cheers
Josef
[1] repos/dde_rump/src/server/rump_fs/file_system.cc:91
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. <a class="moz-txt-link-freetext" href="http://goparallel.sourceforge.net/">http://goparallel.sourceforge.net/</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
genode-main mailing list
<a class="moz-txt-link-abbreviated" href="mailto:genode-main@lists.sourceforge.net">genode-main@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/genode-main">https://lists.sourceforge.net/lists/listinfo/genode-main</a>
</pre>
</blockquote>
<br>
</body>
</html>