Hello,
On 08/19/2012 09:15 PM, Jakub Jermar wrote:
Hello,
On 08/16/2012 05:59 PM, Zdenek Bouska wrote:
I found a problem with VFS's namespace_rwlock
Perhaps just a limitation of the current implementation with respect to
future possible uses?
Yes.
(uspace/srv/vfs/vfs_ops.c). It prevents from creating overlayer
filesystems like FUSE's fusexmp.c example [1][2]. Maybe even saving
filesystem data in other filesystem is not possible.
VFS mount => overlayer FS mount => VFS stat on different FS file =>
deadlock
Can you be more specific? What are these 'overlayer' fs trying to do?
Ok, not a good term. Filesystem with it's data stored in other
filesystem. It needs to call VFS IN protocol from it own implementation
of VFS OUT protocol. For example it could unzip or decrypt files, log
operations with files or it could have it's encrypted/zipped data stored
in one big file.
There is comment near the rwlock:
"This rwlock prevents the race between a triplet-to-VFS-node resolution
and a concurrent VFS operation which modifies the file system namespace."
Is there another way how to prevent this race? Something like different
lock for each mounted FS.
The namespace_rwlock is a simple solution for making sure the file
namespace does not change under our hands, but it has its own problems.
Surely one can change the implementation to use a more fine-grained
locking scheme and adapt the rest of VFS to it.
Ok. I'm now testing fusexmp with namespace_rwlock commented. Since
fusexmp is only example for testing that's enough for me now. We could
postpone this before porting or creating useful filesystem limited by this.
Zdenek
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
