Bug#1116067: linux-image-6.1.0-32-amd64: btrfs compression quietly stopped around 60TB in
On Tue, Oct 14, 2025, at 10:05 PM, james young wrote:
> I started btrfs check with the progress option; within two hours, it
> had gotten to “[2/7] checking extents, 82 items checked”.
> I confused the extents with the compressed chunk length - 128KiB - so
> that seemed woefully low on progress.
> Over a week later, it’s still "82 items checked".
> It’s still taking CPU (3% right now) and gigs of memory; it’s doing
> something, though slowly.
>
> So, a question:
> * is this business as usual for a btrfs check?
> * is this a clue about what happened?
> * is this a symptom?
I think it's understood fsck doesn't scale with storage, for any file system.
The very idea of btrfs originally was to be always consistent and not need fsck *if* the storage stack is honoring flush and fua. So then it's understood sometimes there are write time bugs, hence newer kernels have read time and write time tree checkers to check for the common issues.
On xfs they've implemented an online file system repair capability. Again, it just takes too much offline time to run traditional fsck on big file systems.
I have no idea how long 151G of metadata will take for btrfs check. It's very memory dependent. There is a lowmem mode for btrfs check but it is even slower. I'd say it's not worth it to run the btrfs check at all if this is also a 6.1 version btrfs-progs. Too many changes have happened since then. But in any case, it's such a big file system, I'm not sure it's worth it anyway if it still mounts.
I'm having a hard time understanding which file system actually broke or if they both did. And there isn't a complete dmesg.
Also, I'm not a btrfs developer. I think it would help improve the chances for a response to have a simpler reproducer of the problem with current stable kernel at the oldest, but ideally mainline. Pretty sure Debian offers them in unstable backports or something like that.
--
Chris Murphy
Reply to: