The existing cleanup code would silently cancel disk IO requests, if
somehow the calling code did not wait for completion. This code now
tracks requests and will bug if any are lost.
Signed-off-by: Justin Husted <sigstop@gmail.com>
The shutdown code in d79d57e and b20e160 had a race condition during
shutdown, due to not owning a reference on the associated task_struct
while the associated threads shut themselves down.
Patch over this by taking an appropriate reference.
Signed-off-by: Justin Husted <sigstop@gmail.com>
The ktime_get_coarse_real_ts64() implementation for userspace was using
CLOCK_MONOTONIC instead of CLOCK_REALTIME_COARSE. This resulted in
files being timestamped with a time close to the unix epoch.
Signed-off-by: Justin Husted <sigstop@gmail.com>
So far, these tests just test basic format, fsck, and list functions
under valgrind, as well as a few self-validation tests.
Signed-off-by: Justin Husted <sigstop@gmail.com>
This is part of the userspace implementation of the kernel APIs for
bcachefs-tools. The previous implementation just provided a barrier, but
this isn't sufficient to make the associated percpu implementation safe.
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.
