| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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>
|
|
The BTREE_INSERT_ATOMIC removal broke fuse.
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>
|
|
The write buffer was being leaked in bcachefs_fuse_write().
Signed-off-by: Justin Husted <sigstop@gmail.com>
|
|
Signed-off-by: Justin Husted <sigstop@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also fix link.
|
|
testing, but there are problems with cache coherency and journaling.
|
|
|
|
|
|
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.
|
|
bcachefs fusemount dev mountpoint
or
bcachefs fusemount dev1:dev2:... mountpoint
|
|
|
