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