Bug 243925 - [FUSEFS] Read operation on a write only file
Summary: [FUSEFS] Read operation on a write only file
Status: Closed Not A Bug
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: Alan Somers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-06 12:27 UTC by Agata
Modified: 2020-02-14 06:45 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agata 2020-02-06 12:27:35 UTC
FreeBSD 12.1 introduced a bug that was not present in previous versions.

When using a FUSE-based file system, user tries to append data to a file that is not cached. File is opened WRITE ONLY, but the first call after open is read, not write. This is not an allowed behaviour and some file systems will return EACCESS error.

If the file is cached, then there is no read, only write.

This bug is still present in 13.0 CURRENT (20200130).
Comment 1 Conrad Meyer freebsd_committer 2020-02-06 23:28:26 UTC
Can you share a specific ordering of IPCs, including exact open flags used and FUSE procedures seen on the server side?

For cached IO (bio) without O_DIRECT, we probably attempt to read the last page/sector of a file we are appending to.  Any local filesystem would do something similar (read a block from the backing volume when a write-only append handle is open for an uncached, cacheable file), if the file is not a perfect multiple of the page size.

I think we mostly try to open separate read handles for this, but it's we missed a case.  Any specific details you can share would be helpful.  Thanks.
Comment 2 Alan Somers freebsd_committer 2020-02-07 04:55:32 UTC
This is not a bug; it's the documented behavior of the FUSE protocol.  See https://github.com/libfuse/libfuse/blob/562223325e6dd2fde2f4e0077dac7e1c44e3dd18/include/fuse.h#L403 .  The purpose of the open flags is access control.  FUSE file systems should always be prepared to handle reads.  If the file system can't, then it should not allow itself to be mounted with the writeback cache.

File system daemons using protocol 7.23 or later can control whether the writeback cache is enabled.  For older daemons, the writeback cache is controlled by the vfs.fusefs.data_cache_mode sysctl.

Before I close this bug, can you please confirm your current cache mode?  To do that, report the value of the vfs.fusefs.data_cache_mode sysctl, report the name and version of the FUSE file system you're using, and (if it uses libfuse), show the daemon's debug output, if it provides any.
Comment 3 Agata 2020-02-14 06:45:13 UTC
Yes, the affected file system used write back cache. This is quite unexpected behaviour, nevertheless, since it's documented, it's not a bug, it's a feature ;) Thank you for pointing it out.