jnr-fuse
jnr-fuse copied to clipboard
Do you plan to support libfuse3?
Hi! libfuse2 is almost not developing, unlike version 3. Are you planning to upgrade to version 3?
Hi, @TheHett! What problem are you observing with libfuse3? As far as I can see, no APIs were changed. The only change that could have broken jnr-fuse is a failure to resolve the library.
@SerCeMan As I understand it, the API has changed. I tried to compile utility httpfs2 ( http://httpfs.sourceforge.net ) written on C for libfuse2 but stocked with incompatibility.
I have tried to use libfuse3.so and encountered an error:
fuse: unknown option(s): `-o big_writes,max_write=131072,direct_io' Exception in thread "main" ru.serce.jnrfuse.FuseException: Unable to mount FS at ru.serce.jnrfuse.AbstractFuseFS.mount(AbstractFuseFS.java:286) at alluxio.fuse.AlluxioFuse.main(AlluxioFuse.java:71) Caused by: ru.serce.jnrfuse.FuseException: Unable to mount FS, return code = 3 at ru.serce.jnrfuse.AbstractFuseFS.mount(AbstractFuseFS.java:282) ... 1 more
It seems that fuse3 changed some options.
Hey, @TheHett! If I understand correctly, the utility that you tried to compile was in c. For jnr-fuse, only binary compatibility is important. I'll try to check whether the smoke tests pass with fuse3 installed.
Hey, @xuchen-plus! I believe these parameters are specified by alluxio, https://github.com/Alluxio/alluxio/blob/master/docs/_data/table/Alluxio-FUSE-parameter.csv.
Looking at the release notes, it seems like the option was removed from libfuse:
The
-o big_writes
mount option has been removed. It is now always active. File systems that want to limit the size of write requests should use the-o max_write=<N>
option instead.
It's probably worth exposing these options either programmatically or at least providing a check that allows for checking the fuse version from java.
It seems that fuse3 changed some options.
However, the error message confirms that the fuse library is discovered correctly.
But when I tried to run alluxio with fuse3.9, the fuse reported it's not compatible in API level.
root@iZj6c61fdnjcrcrc2sevsfZ:/# ls /alluxio-fuse/
ls: reading directory '/alluxio-fuse/': Function not implemented
root@iZj6c61fdnjcrcrc2sevsfZ:/alluxio-fuse# cp /alluxio-fuse/abc /tmp
cp: cannot open '/alluxio-fuse/abc' for reading: Operation not supported
And in the logs of alluxio-fuse, I noticed:
Starting alluxio-fuse on local host.
fuse: warning: library too old, some operations may not not work
2020-01-28 12:27:51,023 INFO AlluxioFuseFileSystem - getattr(/)
2020-01-28 12:28:08,682 INFO AlluxioFuseFileSystem - getattr(/)
2020-01-28 12:28:33,593 INFO AlluxioFuseFileSystem - getattr(/)
2020-01-28 12:28:41,152 INFO AlluxioFuseFileSystem - getattr(/)
2020-01-28 12:28:45,814 INFO AlluxioFuseFileSystem - getattr(/abc)
2020-01-28 12:28:45,815 ERROR AlluxioFuseFileSystem - Truncate is not supported /abc
fwiw this doesn't work at all with libfuse3
. the fuse_operations
struct has changed.
@SerCeMan One thing I discovered is that only FUSE 3 supports fuse_fill_dir_flags
and the option to return file stats in readdir
which the kernel caches. This is useful to simplify, eg, an S3 client because the S3 API returns file stats during listing. Otherwise they need to be cached manually. Similarly, I see a cache_readdir
flag in fuse_file_info
which should cache readdir results. Very useful stuff.