When I try to delete a previous created btrfs subvolume I get this:
ERROR: Could not statfs: Value too large for defined data type

The same when I try to make a btrfs snapshot.




Copy-paste of console:

root@ODROID-HC2:/media/nas# btrfs subvolume list /media/nas
ID 318 gen 1216 top level 5 path 2023-03-13

root@ODROID-HC2:/media/nas# btrfs subvolume delete /media/nas/2023-03-13
ERROR: Could not statfs: Value too large for defined data type

root@ODROID-HC2:/media/nas# btrfs --version
btrfs-progs v5.10.1

root@ODROID-HC2:/media/nas# uname -a
Linux ODROID-HC2 4.14.294+ #1 SMP PREEMPT Sat Sep 24 10:24:15 UTC 2022
armv7l GNU/Linux

root@ODROID-HC2:~# ldd --version
ldd (Debian GLIBC 2.31-13+deb11u5) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

root@ODROID-HC2:~# dpkg --status btrfs-progs
Package: btrfs-progs
Status: install ok installed
Priority: optional
Section: admin
Installed-Size: 3238
Maintainer: Adam Borowski <kilobyte@angband.pl>
Architecture: armhf
Multi-Arch: foreign
Version: 5.10.1-2
Depends: libblkid1 (>= 2.17.2), libc6 (>= 2.8), libcom-err2 (>=
1.43.9), libext2fs2 (>= 1.42), liblzo2-2 (>= 2.02), libmount1 (>=
2.24.2), libuuid1 (>= 2.16), libzstd1 (>= 1.4.0), zlib1g (>= 1:1.2.0),
libgcc-s1 (>> 10-20200211)
Suggests: duperemove
Breaks: btrbk (<= 0.25.0), initramfs-tools (<< 0.137~), libgcc-s1 (<<
10-20200211)
Description: Checksumming Copy on Write Filesystem utilities
 Btrfs is a copy on write filesystem for Linux aimed at implementing
 advanced features while focusing on fault tolerance, repair and easy
 administration.
 .
 This package contains utilities (mkfs, fsck) used to work with btrfs
 and an utility (btrfs-convert) to make a btrfs filesystem from an ext3.
Homepage: http://btrfs.wiki.kernel.org/

Hi, there are known issues with large filesystems on 32-bit.  Not just
btrfs for that matter -- it's just more likely to be affected because of
native multi-device support and two layers of addressing.

Thus:
* how big is the filesystem?
* does it consist of multiple devices?
* has it been rebalanced or converted to a different redundancy profile?

If the sum of all parts that are (or ever have been) included in the
filesystem approaches 8TB, this would be the cause.  In addition, any
address space that was allocated in the past but had been balanced/converted
away is lost -- virtual offsets always go up.  This is not a concern on
64-bit as you can't possibly use them up, but for 32-bit the limit can be
exceeded even with a single large disk.

Other filesystems also suffer from this limit, although MD at least moves
the threshold from being applied to raw device size to the available size
which allows redundant raid as long as the resulting size is below[1] 8TB.

Shedding the limit would require changing many parts of the kernel, and
there is currently no intention of ever doing that.  Thus, I'm afraid you
need to either use a smaller filesystem or a 64-bit kernel (which your CPU
doesn't support).

There's little support for 32-bit in general, it's in maintenance mode
these days...


Did I assume correctly that you ran into the limit?  If not, please say so.
Otherwise, all we can do is improving error messages.


[1]. Because disk manufacturers cheat on the definition of "terabyte",
an "8TB" disk has less than 1099511627776 bytes.