sync() not implemented by rumpfs

Josef Söntgen josef.soentgen at ...1...
Thu Feb 5 10:20:51 CET 2015

Hello Adrian,

* a3an <a3an at ...294...> [2015-02-04 22:14:37 +0100]:
> 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.

No problem, it is not so easy to follow at first.

> 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.

The problem here is the current implementation of rump_fs. Though we
sync the file system regularly and the sync/dirty flag should be
cleared, the “s_state” field in the superblock of Ext2 has not been
updated because the file system is not unmounted. When rump_fs tries
to mount the used image, it checks this field and prints the message.
There is a commit [1], that addresses this issue by mounting the file
system when the first client opens a session and umounting it when the
last client closes its session but it is not on the master branch yet.

So, all in all, the data written to the file system is safe, rump_fs
(and thereby the rumpkernel) does it job and the message can be
ignored. I admit, the current situation is not optimal. It would be
nice, if rump_fs would always do a fsck before mounting the file
system and would only notify the user if something really is wrong.


    (Note the commit is old and may or may not apply to the current
    master branch.)

More information about the users mailing list