sync() not implemented by rumpfs

[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rump_fs_sync_pdbg.patch
Type: text/x-diff
Size: 2315 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20150203/045b82c6/attachment.patch>