Instead of requiring the user to supply all the device nodes for a
multi-device FS, allow them to specifiy 1 of them. We then fetch
the UUID for the FS and then find all the disks on the system that
match this UUID.
This allows me to bring up a bcachefs FS in /etc/fstab by using a
UUID. This works because it appears the mount command looks up
the UUID, finds an entry in /dev/disk/by-uuid and then passes that
found device node to mount.bcachefs which fails with
`insufficient_devices_to_start` as bcachefs is expecting a list of
devices with a ":" between them. This behavior is preserved if a
user specifies a list of all the needed device nodes to bring up
the FS.
Signed-off-by: Tony Asleson <tasleson@redhat.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
This resolves build warnings and failures for architectures where the
Linux userspace `asm/types.h` header defines 64-bit types (u64, s64) as
`long` instead of `long long`.
By defining `__SANE_USERSPACE_TYPES__`, these types are defined as
`long long` instead.
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
- Add key_file option to Cli
- Rework decryption flow logic to first attempt key_file
- Read password from file and pass to decrypt_master_key
Explicity specify '-k' for key_location
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
The second argument to ioctl() can be defined as a different type by
different libc implementations, and can be a different size on different
architectures depending on what type it is defined as. For example,
glibc defines it as `unsigned long` which may have a different size on
32-bit vs. 64-bit architectures, and musl libc defines it as `int`.
The Rust libc crate exposes a type `libc::Ioctl` which is defined as the
appropriate integer type for the given libc implementation. Using this
type for the request argument to `libc::ioctl()` ensures code will
compile correctly regardless of architecture and libc implementation.
Also, because ioctl request numbers are defined to be 32 bits
(regardless of the fact that `unsigned long` might sometimes take 64
bits on some architectures), this patch changes the Rust representation
of the bcachefs ioctl numbers to u32 instead of u64.
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
This patch addresses build issues with bch_bindgen on architectures
where the natural alignment of u64 is 4 instead of 8, such as i686 and
ppc64. The issue arises from rustc's refusing to compile structs with a
"packed" attribute that have members with an explicit "align(N)"
attribute.
rust-bindgen generally does not place "align(N)" attributes on types
when it is redundant with the type's natural alignment. There are a few
types in bcachefs with "__aligned(8)" in C where the type's natural
alignment is 8 except on architectures like those mentioned above where
it is 4. rust-bindgen places the "align(8)" attribute on these types,
for those architectures. The affected types include:
- bch_csum
- bch_sb_layout
- bch_ioctl_data_progress
bch_ioctl_data_progress, and all types that depend on it, are not used
on the Rust side currently and bindings are only generated for them
because they are covered by `.allowlist_type("bch_.*")` in
bch_bindgen/build.rs. This patch resolves the build failure for this
type by excluding it from bch_bindgen. If/when accessing this type in
Rust is needed, a decision can be made then about how to represent its
layout in Rust.
bch_csum and bch_sb_layout, and types that depend on them, are currently
used in Rust so they can't be excluded. This patch addresses these types
by stripping off the "packed" attribute in Rust on types that embed
these types, since that attribute happens to not be necessary for proper
layout.
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
To avoid expensive version upgrades and downgrades - use the kernel
version of fsck when it's availale and a better match.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
