Age | Commit message (Collapse) | Author | Lines |
|
In order to use the fuse_fill_dir_t function in a C++ program, add the enum item:
FUSE_FILL_DIR_DEFAULTS
Without this change g++ compilation failed with
example/hello.c:94:35: error: invalid conversion from ‘int’ to ‘fuse_fill_dir_flags’ [-fpermissive]
94 | filler(buf, ".", NULL, 0, 0);
| ^
| |
| int
|
|
Shared locks (parallel_direct_writes) cannot be enabled for O_DIRECT, as
O_DIRECT may be set past file open time with fcntl(fd, F_SETFD, ...).
Kernel side fuse has precautions for shared lock direct-IO (direct_io in
libfuse), as it needs an exclusive inode lock when direct and page cache
IO happend at the same time.
In order to enjoy the parallel_direct_writes feature (i.e., get a shared
lock, not exclusive lock) for writes to the same file), direct_io is needed.
The feature direct_io is corresponding to FOPEN_DIRECT_IO in fuse kernel.
FOPEN_DIRECT_IO and O_DIRECT are not entirely the same as described above.
So enable direct_io (i.e., FOPEN_DIRECT_IO in fuse kernel) to enjoy parallel
direct_writes.
Some patches related to FOPEN_DIRECT_IO and O_DIRECT are below:
https://lore.kernel.org/all/753d6823-e984-4730-a126-d66b65ea772c@ddn.com
|
|
Move the parallel_direct_writes enable action to the init function in high level API,
it is more recommended just like commit 8ee553dac. Besides, add some comments to show
that the feature parallel_direct_writes is depend on the feature direct_io (refer to
kernel side patch series to consolidate direct IO, link: https://lwn.net/ml/linux-fsdevel/
20230918150313.3845114-1-bschubert@ddn.com for the reason).
|
|
All these passthrough examples don't need writes to be serialized.
Actually, most file systems probably handle non serialized parallel
direct writes - the FOPEN_PARALLEL_DIRECT_WRITES flag is just
to avoid a regression for those file system that rely on serialized
DIO writes in fuse kernel. Passthrough file system forward the IO
to another file system, which actually handles that internally -
serialized in fuser kernel is not needed.
|
|
This addresses: https://github.com/libfuse/libfuse/issues/724
HAVE_LIBC_VERSIONED_SYMBOLS configures the library if to use
versioned symbols and is set at meson configuration time.
External filesystems (the main target, actually)
include fuse headers and the preprocessor
then acts on HAVE_LIBC_VERSIONED_SYMBOLS. Problem was now that
'config.h' was not distributed with libfuse and so
HAVE_LIBC_VERSIONED_SYMBOLS was never defined with external
tools and the preprocessor did the wrong decision.
This commit also increases the the minimal meson version,
as this depends on meson feature only available in 0.50
<quote 'meson' >
WARNING: Project specifies a minimum meson_
version '>= 0.42' but uses features which were added
in newer versions:
* 0.50.0: {'install arg in configure_file'}
</quote>
Additionally the config file has been renamed to "fuse_config.h"
to avoid clashes - 'config.h' is not very specific.
|
|
IN a bunch of comments we say 'under the terms of the GNU GPL', make
it clear this is GPLv2 (as LICENSE says).
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
|
|
|
|
|
|
The passthrough example filesystem can be used for validating the API
and the implementation in the FUSE kernel module.
|
|
|
|
|
|
Required for better hardlink handling, see comments in patch.
|
|
Fixes: #81.
|
|
Modifying struct fuse_config in the init() handler is the canonical way
to adjust file-system implementation specific settings. There is no need
to have flags in struct fuse_operations.
|
|
Several options (use_ino, etc) depend on the file system
implementation. Allowing them to be set from the command line makes no
sense.
|
|
This obsoletes the ftruncate & fgetattr handlers.
Fixes #58.
|
|
Also, added more comments for the same purpose.
|