Am Samstag, 23. November 2019, 00:21:18 CET schrieben Sie: > Am Freitag, 22. November 2019, 02:36:56 CET schrieb Chris Murphy: > > On Thu, Nov 21, 2019 at 3:39 PM Marc Joliet <marcec@xxxxxx> wrote: > > > On a side note, I am also really annoyed by the lockups caused by > > > qgroups. > > > On my Gentoo systems (which use btrbk) I have it disabled for that > > > reason, but I left it on on my openSUSE laptop (a Dell XPS 13 9360), > > > which locks up for about 15-30 minutes while cleaning up snapshots a few > > > times a week (usually after reboots or after "zypper dup"). > > > > 15 seconds is not at all acceptable on a desktop system, 15 minutes is > > atrocious. A computer that appears to hang for 15 seconds, it is > > completely reasonable for ordinary users to consider has totally > > faceplanted, will not recover, and to force power off. The > > distribution really needs to do something about that kind of negative > > user experience. > > Sadly, I can't say if it's better without snapshotting /home, because I > hadn't accumulated many / snapshots at that point in time. It might have > gotten worse even with only / being snapshotted. But like I said, I'll > experiment with configuring snapper before blaming SUSE. I believe the > installation even recommends against snapshotting /home, but hey, I wanted > to do it anyway :-) . > > But to be precise, it's not locked up continuously during snapshot deletion. > Occasionally I'll be able to operate my desktop for a few seconds, and if I > leave top running in a GUI terminal (in my case konsole), I'll see it > updating (almost) the entire time. My guess (emphasis on *guess*) is that > the qgroups update is holding some lock that is preventing other I/O from > finishing, thus locking up any application that wants to write to disk and > isn't doing so concurrently (maybe Plasma is blocking on fsync() at the > time?). So just to follow up on this, reducing the total number of snapshots and increasing the time between their creation from hourly to once every six hours did help a *little* bit. However, about a week ago I decided to try an experiment and added the "autodefrag" mount option (which I don't usually do on SSDs), and that helped *massively*. Ever since, snapper-cleanup.service runs without me noticing at all! [ What made me try it was that booting the laptop and logging in started getting really slow and top was showing several btrfs-endio threads hogging the CPU, *before* snapper-cleanup.service or anything else specific to btrfs was running (their activity usually coincided with KDE Baloo activity), i.e., general I/O was performing badly. ] Greetings -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
Attachment:
signature.asc
Description: This is a digitally signed message part.
