Hi Josef,

I installed the patch and it shows that fsync result in calling sync(). Actually I used fsync(0).

[init -> test-libc_vfs] Trying sync()
[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 sync()     <---------------------------- this my trace in 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] sync() done
[init -> test-libc_vfs] test finished
[init] virtual void Genode::Child_policy::exit(int): child "test-libc_vfs" exited with exit value 0

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.

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.
So if sync() was successfully executed in the first run, the second run should find a clean file system.
Which is not the case:

[init -> rump_fs] Backend::Backend(): Backend blk_size 512
[init -> rump_fs] rump: /genode: file system not clean; please fsck(8)
[init -> test-libc_vfs] calling mkdir(dir_name, 0777) dir_name=testdir
[init -> test-libc_vfs] mkdir(dir_name, 0777) failed, ret=-1, errno=28
[init] virtual void Genode::Child_policy::exit(int): child "test-libc_vfs" exited with exit value -1

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.

In the Unix/Linux world one normally does not issue a sync() call at the end of a program (unless
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.

Originally I tried to to solve the lack of an explicit sync call by placing the sync() in the
destructor of the System_component class. But as far as I can see, this destructor is never
called. Is there a graceful shutdown process in Nova ? Or, to be more specific, is rump_fs signaled
that Nova is being shutdown ?

What does this mean for Nova applications ? Must they organize save shutdown of a file system ?
How would they do that ?

Regards, Adrian


Am 03.02.2015 um 19:13 schrieb Josef Söntgen:
Hello Adrian,

* a3an <a3an@...294...> [2015-01-30 10:56:45 +0100]:

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.

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


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.

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



------------------------------------------------------------------------------
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. http://goparallel.sourceforge.net/


_______________________________________________
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main