| ▲ | o11c 3 days ago | |
In my experience, "hung task" is almost always due to running out of RAM and the scheduler constantly thrashing instead of doing useful work. I rarely actually reach the point of seeing the message since I'll sysrq-kill if early enough, or else hard-reboot. Note also that modern filesystems do a lot of background work that doesn't strictly need to be done immediately for correctness. (of course, it also seems common for people to completely disregard the well-documented "this feature is unreliable, don't use it" warnings that btrfs has, then complain that they have problems and not mention that they ignored the warnings until everyone is halfway through complaining) The only problems I've encountered in all my years of using btrfs are: * when (all copies of) a file bitrots on disk, you can't read it at all, rather than being able to copy the mostly-correct file and see if you can hand-correct it into something usable * if you enable new compression algorithms on your btrfs volume, you can't read your data from old kernels (often on liveusb recovery disks) * fsync is slow. Like, really really slow. And package managers designed for shitty CoW-less filesystems use fsync a lot. | ||
| ▲ | jeffbee 3 days ago | parent | next [-] | |
Hung tasks due to low memory are a bug not a feature. Any time you put the Linux kernel under memory pressure you trigger its wealth of defects in error handling paths, none of which are tested and most of which are rarely exercised in practice. For example squashfs used to have a resource leak under memory pressure where it would exit a function without releasing a lock, after which all block operations system-wide would hang forever until reboot. Linux is absolutely crawling with that type of defect, but not uniformly. Some subsystems have more than others, and btrfs is unusually dense with them. | ||
| ▲ | bhaney 3 days ago | parent | prev [-] | |
> In my experience, "hung task" is almost always due to running out of RAM In my case, I don't think this machine ever commits more than around 5GB of its 32GB available memory, so I doubt it's that. > it also seems common for people to completely disregard the well-documented "this feature is unreliable, don't use it" warnings that btrfs has Now that I am definitely doing. I won't give up raid6 until it eats all my data for a fourth time. | ||