Do you plan to support libfuse3? about jnr-fuse HOT 9 OPEN

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

from jnr-fuse.

fwiw this doesn't work at all with libfuse3. the fuse_operations struct has changed.

from jnr-fuse.

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.

from jnr-fuse.

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.

from jnr-fuse.

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.

from jnr-fuse.

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.

from jnr-fuse.

It seems that fuse3 changed some options.

However, the error message confirms that the fuse library is discovered correctly.

from jnr-fuse.

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

from jnr-fuse.

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

from jnr-fuse.