Pre-release build checks are not yet done in the CI, so add a workflow
for that and only for the release-test branch as this usually does not
break and can take a long time due to the number of options (even with
ccache).
Signed-off-by: David Sterba <dsterba@suse.com>
Update the build test script with LZO optional build and add combination
of all existing options with the experimental build (this effectively
doubles the number of build runs).
Signed-off-by: David Sterba <dsterba@suse.com>
The unified naming API of libbtrfsutil is exported in the library, we
should use it in the internal code as well. In the future the old naming
scheme will be deprecated and remove.
Signed-off-by: David Sterba <dsterba@suse.com>
As of bfcf6d04f8ee ("btrfs: handle FS_IOC_READ_VERITY_METADATA ioctl")
the kernel supports FS_IOC_READ_VERITY_METADATA for btrfs (6.14). Add
that to the docs.
Pull-request: #970
Signed-off-by: Allison Karlitskaya <allison.karlitskaya@redhat.com>
Signed-off-by: David Sterba <dsterba@suse.com>
There was a question in the mailing list regarding option --quiet and
why it's not working as 'btrfs subvolume create --quiet ...'.
Historically there were per-command verbosity options but this was
unified under the global options with it's specific syntax. This is not
uncommon and e.g. git also does have this option split.
The documentation and help strings are not making this clear enough, so
print syntax examples at the end of the help of 'btrfs', and do other
adjustments.
Signed-off-by: David Sterba <dsterba@suse.com>
Currently if "btrfs qgroup show" detects the qgroup is in an
inconsistent state, it will print a warning:
WARNING: qgroup data inconsistent, rescan recommended
But the detection is based on the tree search ioctl, and qgroup tree is
only updated at transaction commit time.
This means if qgroup is marked inconsistent, and the transaction is not
commit, there can be a time window as long as 30s before "btrfs qgroup
show" gives a proper warning about inconsistent qgroup numbers.
To address this, use the
'/sys/fs/btrfs/<fsid>/qgroup/inconsistent' file to do extra check.
That file is updated at real time, thus there is no delay, and can give
an early warning about inconsistent qgroup numbers.
Link: https://bugzilla.suse.com/show_bug.cgi?id=1235765
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This allows experimental btrfs-convert builds to handle 2K block sized
ext4, which is needed to pass convert related test cases in fstests.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Since btrfs only supports block size 4K and PAGE_SIZE, on x86_64 it
means we can not test subpage block size easily.
With the recent kernel change to support 2K block size for debug builds,
also add 2K block size support for btrfs-progs, so that we can do proper
subpage block size testing on x86_64, without acquiring an aarch64
machine.
There is a limitation:
- No support for 2K node size
The limitation is from the initial mkfs tree root, which can only have
a single leaf to contain all root items.
But 2K leaf cannot handle all the root items, thus we have to disable
it.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Inside the function btrfs_add_to_fsid(), we allocate a buffer to write
the superblock to disk.
However the buffer size is based on block size, which can cause two
problems:
- 2K block size
The block size is too small for the super block, and we will write
beyond the buffer and corrupt the memory.
- 16/64K block size
The block size will be larger than super block size, this will not
cause any problem but waste some memory.
Fix the bug by using BTRFS_SUPER_INFO_SIZE as the correct buffer size.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
There was an attack on the changed-files action [1] that is used in the
devel workflow, started only after the branch devel is pushed, currently
possible only by 2 people. There was one run of GH actions that used the
compromised version and only the temporary github tokens (github_token,
system.github.token, with the "ghs_" prefix) were visible in the logs.
Their lifetime is said to be 24hours. No other tokens or secretes were
affected.
As recommended, bump the version to v46. We may reimplement the action
eventually as it's quite simple for our needs.
[1] https://www.ox.security/15-hours-of-open-sourced-hell-lessons-learned-from-tj-actions-changed-files/
Signed-off-by: David Sterba <dsterba@suse.com>
Print the warning instead of hard exit when updating source CI docker
images, it will fail for everyone else anyway.
Signed-off-by: David Sterba <dsterba@suse.com>
The disk max size cannot be 256MiB because Btrfs does not allow creating
a filesystem on disks smaller than 256MiB.
Remove the incorrect warning for the 'max' option.`
$ btrfs fi resize max /btrfs
Resize device id 1 (/dev/sda) from 3.00GiB to max
WARNING: the new size 0 (0.00B) is < 256MiB, this may be rejected by kernel
Fixes: 158a25af0d ("btrfs-progs: fi resize: warn if new size is < 256M")
Reviewed-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The zlib and zstd compression methods support using compression levels.
Enable defrag to pass them to kernel.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Daniel Vacek <neelx@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
When compression is null the code always goes through the LZO case,
or prints "lzo support not compiled in".
This bug was added by commit c6d24a363d ("btrfs-progs: mkfs: add lzo
to --compress option").
Pull-request: #967
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The alias should be for btrfs_util_subvolume_snapshot instead of
btrfs_util_snapshot_snapshot.
Pull-request: #969
Signed-off-by: Junxuan Liao <ljx@cs.wisc.edu>
Signed-off-by: David Sterba <dsterba@suse.com>
Replace the use of IOW as abbreviation of "In other words" with the
original expanded meaning, as users who don't have English as their
first language may not know what it means.
Pull-request: #966
Signed-off-by: David Sterba <dsterba@suse.com>
When one of two zones composing a DUP block group is a conventional zone, we
have the zone_info[i]->alloc_offset = WP_CONVENTIONAL. That will, of course,
not match the write pointer of the other zone, and fails that block group.
This commit solves that issue by properly recovering the emulated write pointer
from the last allocated extent. The offset for the SINGLE, DUP, and RAID1 are
straight-forward: it is same as the end of last allocated extent. The RAID0 and
RAID10 are a bit tricky that we need to do the math of striping.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Just same as the kernel side.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Implement it just like the kernel side.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Implement it just like the kernel side.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
DUP support is added like the kernel side.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Currently, the userland tool only considers the SINGLE profile, which make it
fail when a DUP block group is created over one conventional zone and one
sequential required zone.
Before adding the other profiles support, let's factor out per-profile code
(actually, SINGLE only) into functions just like as the kernel side.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Now that, we have zone capacity and (basic) zone activeness support. It's time
to factor out btrfs_load_zone_info() as same as the kernel side.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Introduce "zone_is_active" member to struct btrfs_block_group and activate it
on loading a block group.
Note that activeness check for the extent allocation is currently not
implemented. The activeness checking requires to activate a non-active block
group on the extent allocation, which also require finishing a zone in the case
of hitting the active zone limit. Since mkfs should not hit the limit,
implementing the zone finishing code would not be necessary at the moment.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Properly load the zone activeness on the userland tool. Also, check if a device
has enough active zone limit to run btrfs.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The userland tools did not load and use the zone capacity. Support it properly.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This is an userland side update to follow kernel-side commit 15c12fcc50a1
("btrfs: zoned: introduce a zone_info struct in
btrfs_load_block_group_zone_info"). This will make the code unification easier.
This commit introduces zone_info structure to hold per-zone information in
btrfs_load_block_group_zone_info.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Introduce min_not_zero() macro from the kernel.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Some tests in mkfs or misc require the experimental build. Enable it on
the development workflows. Build coverage with or without experimental
build is covered by the CI image build tests.
Signed-off-by: David Sterba <dsterba@suse.com>
Commit 5bd97022f3 ("btrfs-progs: check: add support for squota")
does ulist node allocation but this leaks on any error before the final
accounting. As it's freed right after that we can use on-stack variable
for that.
This was reported by 067-btrfstune-simple-quota with enabled ASAN with
enabled experimental features.
Signed-off-by: David Sterba <dsterba@suse.com>
When a subvolume is deleted with the recursive option, any nested
subvolumes also get removed without reporting it. Update the subvolume
delete command to print the list of nested subvolumes.
Issue: #923
Signed-off-by: Sidong Yang <realwakka@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Fix a option typo in the mkfs help (`mkfs.btrfs -h`) introduced in the
most recent public release: `defalut-ro` instead of `default-ro`.
Pull-request: #958
Signed-off-by: David Sterba <dsterba@suse.com>
Add "duration" format in seconds to fmt_print which will convert the
input to one of the following strings:
1. if number of seconds represents more than one day, the output will be
for example: "1 days 01:30:00" (left the plural so parsing back the
string is easier)
2. if less then a day: "23:30:10"
Author: Racz Zoltan <racz.zoli@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
In v6.14 kernel release, btrfs will force a direct IO to fall back to
a buffered one if the inode requires a data checksum.
This will cause a small performance drop, to solve the false data
checksum mismatch problem caused by direct IOs.
Although such a change is small to most end users, for those requiring
such a zero-copy direct IO this will be a behavior change, and this
requires a proper documentation update.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Commit 83bd999c3e ("libbtrfsutil: python: use version from primary
VERSION file") still does not fix all packaging problems. The release
build does not see the file.
Signed-off-by: David Sterba <dsterba@suse.com>
The version file of the python subpackage had to have the version set
manually in setup.py due to the out-of-tree build where it was not
possible to access the file VERSION. Manual update was error prone.
Improve that by adding a separate file template that is finalized with
the version during the configure phase. Then it's inclded in setup.py as
it's in the same directory.
There are two exceptions when the file is not required to run setup.py:
- clean - allow running 'make clean' in partially configured directory
- (no arguments) - show the help and commands
In all other cases the file version.py must exist.
Signed-off-by: David Sterba <dsterba@suse.com>
