Description
First of all, I wanted to congratulate @gkostka and other contributors on this excellent library.
Now, I am considering to integrate lwext4 into the OSv unikernel to add ext4 support. The only read-write filesystem OSv supports right now is ZFS which on the one hand has many excellent features but it is also quite "heavy" and has other downsides (not very good support on many Linux distributions).
In my case, I would be integrating lwext4 with the VFS layer in a similar way this RTOS fork of lwext does - https://github.com/RT-Thread-packages/lwext4/blob/master/ports/rtthread/dfs_ext.c#L226-L243.
However, I anticipate my integration will not be very performant in the OSv context when multiple application threads interact with the lwext4 layer. As I understand most high-level API functions in the ext4.c use exclusive global lock (see EXT4_MP_LOCK(mp) and EXT4_MP_UNLOCK(mp)) which in effect enforces sequential processing. For example, no two files can be read, or written, or accessed simultaneously, unless I read the code incorrectly.
The OSv's VFS layer locks access at each vnode level so I could try to disable EXT4_MP_LOCK by never calling ext4_mount_setup_locks() but I am afraid this will lead to the filesystem corruption. For example, we would need to make sure that the bcache, the inode tables, and the file metadata stay consistent and that no single block is used by two different files when multiple threads try to call various ext4_... functions in ext4.c.
Could you please advise where in the code should I add relevant thread synchronization primitives to enforce the data integrity of the ext4 filesystem? At least one part that seems obvious is ext4_bcache, but I would imagine there is logic that allocates new blocks when appending to files or other places where we update inodes or block groups which would have to be guarded as well.
Any help would be greatly appreciated.