[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
From:       Chris Murphy <lists () colorremedies ! com>
Date:       2020-07-11 14:17:18
Message-ID: CAJCQCtQTmsO7NTM+mjB8wZC18YL-4v-022pS31vC_c9cs3USnA () mail ! gmail ! com
[Download RAW message or body]

On Sat, Jul 11, 2020 at 5:55 AM Antti <antti.aspinen@gmail.com> wrote:

> For example btrfs has for a long-time had this issue where after several months and \
> being maybe more than 75% of disk space being in use, that when run on SSDs, system \
> can randomly stops reading from the file system, starts thinking and then \
> eventually returns. With each freezing the condition gets worse and eventually the \
> system is eternally stuck and power reset is required.

This is not normal and not acceptable. It is unfortunately true that
there is a disproportionate burden placed on those having problems no
one else is having. And troubleshooting amounts to either poking it
with a stick (try this! no, try this! ok, now try this!) or providing
sufficiently detailed reproduction steps. And that's tedious too.

> The way this happens for example if you open Gnome Shell application launcher \
> several times in a row, then likelyhood that Gnome completely freezes for duration \
> of some seconds up to one minute increases. I don't see this behaviour when using \
> any other file system so I've attributed it to btrfs but I have no way of knowing \
> if it is an actual issue in btrfs other than it stopped when disk gets formatted to \
> anything else.

My suggestion for any such freeze/hang is to issue sysrq+t. This might
not be easy to do at exactly the time of the hang, because the hang
prevents it from being typed fast enough. (a) remote ssh session with
sysrq+t typed out and ready to just hit enter (b) netconsole, same
concept. Reproduce the problem and then hit enter. Then file a bug
with 'journalctl -k -o short-monotonic > bug#_journal.txt' - likely
the default dmesg buffer will be too small to hold everything but the
journal will have it. That should expose the nature of the hang.

If kernel messages show there's a blocked task for 2 minutes, in that
case it's better to use sysrq+w.

In this case it's not necessary to have extremely detailed
reproduction steps, nor wait for someone to have a properly aged
system to see what's going on.


> And also notice that I wrote "maybe 75% full" because there is no way to know the \
> actual free disk space from just "df -h". There are chapters about this in btrfs \
> FAQ pages that df lies about disk space when using btrfs since evaluating free disk \
> space in btrfs system is a tricky and challenging task with no good solution in \
> sight. This is why e.g. use of "btrfs fs usage /" is required together with other \
> tools to have some idea of available disk space.

In the single device case, 'df' is expected to tell the truth. In the
multiple device case, it should still tell the truth, but can be
confusing because it can't tell the whole truth. And for that, there
is 'btrfs filesystem usage /mnt' which provides quite a lot more
information, to the degree it can be confusing at first. But the
single device case is really straight forward, I just use 'df' and
'du' most of the time unless for some reason I want more information.

Recent example of multiple device confusion:
https://bugzilla.redhat.com/show_bug.cgi?id=1855174
https://lore.kernel.org/linux-btrfs/0326afd3-9e14-b682-30e7-1c8ae44813ea@lechevalier.se/T/#t



-- 
Chris Murphy
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



[prev in list] [next in list] [prev in thread] [next in thread]