sync() not implemented by rumpfs

[a3an]

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 at ...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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20150204/ef464cbe/attachment.html>