* changed in Makefile to use recomended fuse api 35;
* force foreground mode, because fuse_daemonize is forking after initalization other bcachefs threads;
* fix fuse_link, there where mistype in fuse_log (the paremeter need to be inum.inum);
* The write_aligned is fixed, by wrapping struct bch_write_op into container with single closure and using end_io callback to release
that closure.
Also, add helpers for the fuse.bcachefs filesystem type; this means we
can now test the fuse version with fstests.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
bcachefs_fuse_setattr and inode_updates_times need to explicitly call
iter_put (the API changed a while back).
Signed-off-by: Justin Husted <sigstop@gmail.com>
bch2_link_trans() in the filesystem side was fixed to do timestamps
properly, but the change to the tools call got lost.
Signed-off-by: Justin Husted <sigstop@gmail.com>
The experimental fuse3 support is not complete yet, and fuse3 is new and
still difficult to install on some platforms.
Make it optional at compile time, and default to off.
Signed-off-by: Justin Husted <sigstop@gmail.com>
The purpose of these tests is to verify that bcachefs fuse support works
as expected, including gathering valgrind errors from the bcachefs
executable.
To do this, bcachefs is executed from a helper thread in the new
util.BFuse class, which goes about setting up and validating the
valgrind data as well as making sure the mount has completed
sufficiently before the test starts executing.
This also includes some basic functionality smoke tests which cover file
creation, timestamps, etc.
Signed-off-by: Justin Husted <sigstop@gmail.com>
Read: There was a missing refcount on the closure.
Write: Unlike in the Linux kernel, we need to manually update the size
and timestamps, otherwise the operation will appear complete when viewed
via the cached inode, but after unmounting and mounting again the write
will be undone.
Also adds partial . and .. support, and implements ENOTDIR error.
The source of this problem was due to the off-by-one interface expected
by readdir. Each directory entry contains a pointer to next, so it
cannot be emitted to the user until the next entry is actually read.
Returning the current position + 1 is insufficient, because the user
will just retry cur + 1 as the start position to see if they've reached
the end of the directory.
Since directory entries are keyed by a 64-bit hash in bcachefs, the
result was that the user would call readdir over and over with what it
believed the next pointer to be until "cur + 1" reached some enormous
64-bit value related to the hash for the "lost+found" entry.
