having fun looking inside btrfs-progs. we are finding truly historic concentrations of linux in this filesystem
like. first off. you would assume a userspace toolkit makes things safer right?
(a) because it does not directly work in kernel memory?
(b) you would assume that there would be some sort of interface to safely communicate?
(c) and the interface would be more stable than building against kernel headers directly?
so they already decided to take a simple concept (recursive quotas applied to subvolumes) and break it: https://github.com/kdave/btrfs-progs/commit/a26bfde051dd5cfdbade7dcaaeb0df770aead6d0
- The qgroup implementation is considered reasonably stable for daily use and has
- been enabled in various distributions.
+ The qgroup mode is considered not recommended for daily usage, unless there is
+ no planned new snapshot/subvolume creation and deletion.
that is reflected on their docsite, but it's written into the quota command, which has absolutely nothing to do with qgroups: https://btrfs.readthedocs.io/en/latest/btrfs-quota.html#stability-and-performance-implications
note the commit says:
Signed-off-by: Qu Wenruo <wqu@suse.com>
the github username is adam900710 and they have lots of free scripts to break btrfs in the kernel
their ci is funny https://github.com/kdave/btrfs-progs/blob/devel/ci/README.md
Running plain docker build may not work as some magic is needed to allow building either the branch from web repository, or from a local git branch provided as a tarball. Docker does not allow conditional image contents so this is pushed to the test build scripts.
so they cannot run git in docker. very curious
https://github.com/kdave/btrfs-progs/blob/devel/ci/images/ci-openSUSE-tumbleweed-x86_64/test-build
here they use wget to pull the URL
https://github.com/kdave/btrfs-progs/blob/devel/ci/ci-build-tumbleweed
cd /tmp
if [ -f "$fname" -a -s "$fname" ]; then
echo "Found local file $fname, not downloading"
else
echo "Missing or empty tar, downloading branch $branch from git"
rm -- "$fname"
wget "$url" -O "$fname"
fi
tar xf "$fname"
but here they just generate it by hand
BRANCH=${1:-HEAD}
if [ "$#" -ge 1 ]; then
shift
fi
HASH=$(git log -1 --format='%h %s' "$BRANCH")
echo "CI: Generate archive from $BRANCH ($HASH)"
git archive --prefix=btrfs-progs-devel/ -o devel.tar "$BRANCH"
echo "$BRANCH $HASH" > GITCOMMIT
tar uvf devel.tar GITCOMMIT
#rm GITCOMMIT
gzip --force --best devel.tar
the absolute fools. they ran tar xf
everyone knows you can't tar xf on a .tar.gz
so i got distracted because i tried pulling the same file with wget and i got uh a lot of messages
ERROR:tcti:src/tss2-tcti/tctildr-dl.c:142:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-tabrmd.so.0
ERROR:tcti:src/tss2-tcti/tcti-device.c:421:Tss2_Tcti_Device_Init() Failed to open specified TCTI device file /dev/tpmrm0: Permission denied
ERROR:tcti:src/tss2-tcti/tctildr-dl.c:142:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-device.so.0
ERROR:tcti:src/tss2-tcti/tcti-device.c:421:Tss2_Tcti_Device_Init() Failed to open specified TCTI device file /dev/tpm0: Permission denied
ERROR:tcti:src/tss2-tcti/tctildr-dl.c:142:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-device.so.0
ERROR:tcti:src/tss2-tcti/tcti-device.c:421:Tss2_Tcti_Device_Init() Failed to open specified TCTI device file /dev/tcm0: No such file or directory
ERROR:tcti:src/tss2-tcti/tctildr-dl.c:142:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-device.so.0
WARNING:tcti:src/util-io/io.c:255:socket_connect() Failed to connect to host 127.0.0.1, port 2321: errno 111: Connection refused
ERROR:tcti:src/tss2-tcti/tcti-swtpm.c:571:Tss2_Tcti_Swtpm_Init() Cannot connect to swtpm TPM socket
good ol' arch linux!
man! this is crazy. so wget in archlinux is here https://gitlab.archlinux.org/archlinux/packaging/packages/wget/-/blob/main/PKGBUILD?ref_type=heads
and it has this line in the prepare() method:
# Build with nettle 4
git cherry-pick -n fd4487b629edea789fc22baac8a6b641e942bb49
where's that from? let's take a look https://gitlab.com/gnuwget/wget/-/merge_requests/73/diffs?commit_id=fd4487b629edea789fc22baac8a6b641e942bb49
#if NETTLE_VERSION_MAJOR >= 4
nettle_md4_digest(&MD4, ntbuffer);
#else
nettle_md4_digest(&MD4, MD4_DIGEST_SIZE, ntbuffer);
#endif
yeah, conditionally truncating the digest size looks like a normal thing to do
it's from a pull request: https://gitlab.com/gnuwget/wget/-/merge_requests/73/diffs?commit_id=896fcbfcd577c29956a059b9e6ea7c01a109eefc which also removes a --disable-ntlm from the configure script options. we'll come back to this