Hacker News new | ask | show | jobs
by cmurf 1501 days ago
I can't reproduce this on a 5.17.5 kernel and loop device. So if you're able to trivially reproduce it, I'm guessing it's configuration specific. It's still a bug, but to find it means providing more detail about that configuration, including the kernel version.

Ideally reproduce it with mainline kernel or most recent stable. And post the details on the linux-btrfs list. They are responsive to bug reports.

If you depend on LTS kernels then it's, OK to also include in the report the problem happens with X kernel but not Y kernel. Upstream only backports a subset of fixes and features to stable. Maybe the fix was missed and should have gone to stable or maybe it was too hard to backports.

These are general rules for kernel development, it's not btrfs specific. You'll find XFS and i915 devs asking for testing with more recent kernels too.

But in any case, problems won't get fixed without a report on an appropriate list.

1 comments

>So if you're able to trivially reproduce it,

Make a VM OpenSUSE or Fedora (tested just these two) fill it and see it not boot anymore...it is trivial.

OK this is a very different scenario than what I thought you were talking about (a broken file system). If a file system is full such that writes aren't possible, boot can fail no matter the file system. This isn't a file system problem. It's a failure to manage space.

Most distros require a read-write /sysroot, and expect the ability to write to disk. If they can't write, various services will fail and that can prevent startup from proceeding further. But without any logs, we have no idea what you're actually experiencing.

You are saying it won't boot but that's not at all a case of a broken file system. It's an expected consequence of the file system being full. Since the examples were clear intent of making the file system completely full, it's a setup to prevent the file system from further writes.

Overwriting file systems are expected to run into this problem less, but aren't immune to it. If the data write requirement is new writes, rather than overwriting, it'll fail whether ext4, XFS or Btrfs. If the requirement involves overwriting, it's expected overwriting file systems will succeed where COW file systems simply can't. It might be a valid argument in favor of non-root users being disallowed to use the last 1-5% of free space on any file system.

>You are saying it won't boot but that's not at all a case of a broken file system

Please read my comment in full especially that point:

- rm blabla && sync

- reboot