This moves the Rust sources out of rust_src/ and into the top level.
Running the bcachefs executable out of the development tree is now:
$ ./target/release/bcachefs command
or
$ cargo run --profile release -- command
instead of "./bcachefs command".
Building and installing is still:
$ make && make install
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
When bcachefs was a C program that had some functions implemented in
Rust, it was necessary to make a static library containing the Rust
functions available for the C program to link.
Now that bcachefs is a Rust program, that library is no longer needed.
Instead, the Rust executable links in libbachefs.a.
This patch updates the crate structure to reflect that. The command
functions are moved into their own module.
There could be a need to create a "libbachefs-tools" library in the
future that exposes an API for bcachefs functionality to other
userspace programs. That will be a different, external API as opposed to
the previous library functions which were an internal API for the
bcachefs tool itself.
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
This moves the main() function from C to Rust. It also updates the name
of the Rust package from "bcachefs-rust" to "bcachefs-tools".
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
We're only reading the superblocks, no need for O_EXCL - and this fixes
mounts failing because we're still holding the devices open.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
The only use for itertools is in parse_mount_options() where we take a
vector, convert it to iterator and then join it. Instead, we can join
the vector directly.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
The memmove() in pop_cmd() reads and writes beyond the end of argv.
This is basically harmless in the current C program; the environment
variable list immediately follows argv so all this does is unnecessarily
copy the beginning of that list.
However, this will become problematic once we start calling C functions
like fs_cmds() from Rust code. Then argv will be a Vec<String> (as
*mut *mut i8) and the memory layout will be different--in particular,
I don't think we can assume that a Vec<String> will be NULL-terminated
like argv always is--, meaning the invalid write could lead to heap
corruption.
Also, it doesn't look like full_cmd ever gets used after calling
pop_cmd() so I'm removing it here since it looks unneeded to me.
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
block_size is in bytes, not sectors, so when calling round_up(),
we could start rounding up by a way too large size and then overflow
outside the area that migrate allocated for us.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Correctly generate libexecdir based path for the bcachefsck_all
service, like the bcachefsck_all_fail service already does.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
this gets us back down to a single fd for opening block devices, which
means we can use O_EXCL.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
not needed with pwritev2(.., RWF_SYNC), and perhaps we can get down to
one fd and then use O_EXCL for block devices.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
The bcachefs sub-commands that are implemented in Rust (completions,
list, and mount) had separate entrypoints and thus had some differences
in behavior.
This introduces a common entry point for the Rust sub-commands. This
reduces duplicate boilerplate code like parsing argv and setting up
logging, and will facilitate converting more sub-commands to Rust in
the future.
An immediate benefit is that this fixes an issue with `bcachefs list`
not reporting errors:
before:
$ bcachefs list /dev/typo
$ echo $?
0
after:
$ bcachefs list /dev/typo
ERROR - bcachefs_rust::cmd_list: Fatal error: "No such file or directory"
$ echo $?
1
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
These are executables that need to be installed in a non-path location.
Most distributions now install these into /usr/libexec, and the
path variable for this is LIBEXECDIR, so use that instead.
This adds a new option to cmd_fsck for using the kernel implementation
of fsck instead of userspace, via the BCH_IOCTL_FSCK_OFFLINE ioctl.
This isn't intended for normal usage - mainly for testing and debugging
purposes, and for when the kernel version of bcachefs better matches the
on disk format version.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Specifically, do not recursively expand $(CFLAGS) because this leads to
repeatedly performing compile tests (e. g. cc-disable-warning) on every
recipe execution.
Without (nproc=32):
```
$ time env -i PATH=/usr/bin BCACHEFS_FUSE=1 NO_RUST=1 make -j$(nproc)
<...>
[LD] bcachefs
72,48s user 11,29s system 190% cpu 44,036 total
```
With:
```
$ time env -i PATH=/usr/bin BCACHEFS_FUSE=1 NO_RUST=1 make -j$(nproc)
<...>
[LD] bcachefs
66,79s user 5,17s system 1955% cpu 3,679 total
```
This should use `cargo clean` instead of `rm -rf ...`. Also,
due to a typo, the `rm` did not actually remove the Rust artifacts.
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
