Age | Commit message (Collapse) | Author |
|
New on disk forat feature - per member 64 bit bitmap of regions with
btree nodes, to accelerate recovering by scanning for btree nodes.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
bch2_dev_btree_bitmap_marked_sectors() shift
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
mount: canonicalize device path for single device node
|
|
also clears should_be_locked
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
If we pass a symlink for a single device node we fail to locate the
device node. Canonicalize the device node before we try to read up
the superblock.
This allows the following to work.
# bcachefs mount /dev/mapper/vg-thinvolume /mnt/lv_thin
Signed-off-by: Tony Asleson <tasleson@redhat.com>
|
|
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
|
|
nodes found by scanning to fill holes
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
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>
|
|
Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
dependencies.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
|
|
Avoid casting away const when processing C command args
|
|
|
|
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
Typo: `filysestem` -> `filesystem`
|
|
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
|
|
|
|
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>
|
|
Specifically also mention locked
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
Also key_location to key_policy
Improve help description key policy
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
- 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>
|
|
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
Signed-off-by: Roland Vet <RlndVt@protonmail.com>
|
|
Output has become much more verbose:
mounting version 1.6: btree_subvolume_children opts=ro,errors=continue,degraded,nochanges,norecovery,read_only
recovering from clean shutdown, journal seq 9
alloc_read... done
stripes_read... done
snapshots_read... done
u64s 16 type inode_v3 0:4096:U32_MAX len 0 ver 0: mode=40755
flags= (16300000)
journal_seq=1
bi_size=0
bi_sectors=0
bi_version=0bi_atime=90363614
bi_ctime=91363625
bi_mtime=91363625
bi_otime=90363614
bi_uid=0
bi_gid=0
bi_nlink=1
bi_generation=0
bi_dev=0
bi_data_checksum=0
bi_compression=0
bi_project=0
bi_background_compression=0
bi_data_replicas=0
bi_promote_target=0
bi_foreground_target=0
bi_background_target=0
bi_erasure_code=0
bi_fields_set=0
bi_dir=0
bi_dir_offset=0
bi_subvol=1
bi_parent_subvol=0
bi_nocow=0
u64s 17 type inode_v3 0:4097:U32_MAX len 0 ver 0: mode=40700
flags= (15300000)
journal_seq=1
bi_size=0
bi_sectors=0
bi_version=0bi_atime=91363625
bi_ctime=91363625
bi_mtime=91363625
bi_otime=91363625
bi_uid=0
bi_gid=0
bi_nlink=0
bi_generation=0
bi_dev=0
bi_data_checksum=0
bi_compression=0
bi_project=0
bi_background_compression=0
bi_data_replicas=0
bi_promote_target=0
bi_foreground_target=0
bi_background_target=0
bi_erasure_code=0
bi_fields_set=0
bi_dir=4096
bi_dir_offset=453699834857023875
bi_subvol=0
bi_parent_subvol=0
bi_nocow=0
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>
|
|
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
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>
|
|
|
|
Add option to read passphrase from a keyfile
|
|
on big endian struct bkey
|
|
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|