Created attachment 1939400 [details]
sadf -g -- -q PSI -s 08:10:00 > sa_PSI.svg

Description of problem:
systemd-oomd will occasionally kill my backup script when I send full snapshot (non-incremental) to my backup drive, it also seems to kill unrelated GNOME desktop components? see journalctl attachment.

Version-Release number of selected component (if applicable):
% oomctl --version
systemd 251 (251.10-588.fc37)
+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

How reproducible:
Mixed; reproducibility seems more consistent when sending full snapshots to backup and actively using my desktop.
I have yet to create a perfect reproduction, but am working on it.

Steps to Reproduce:
1. Send full snapshot between two disks, either in the user.slice or in the 
service.slice
1.a btrfs send /big_snapshot | btrfs receive /mnt/some_other_disk

I hope to have better reproduction in the future.

Actual results:
systemd-oomd will kill the systemd service I use for this or kill the offending terminal that is running this command when it's not put into another systemd slice using systemd-run or ran as a service.


Expected results:
Backups to work without being SIGKILLed

Additional info:

Backup Drive [btrfs recv]: Model(ST8000DM004) P/N(2CX188) Serial(ZCT07N2M)
___
connected via a Sabrent 3.5" harddrive USB UASP enclosure. It is running using the UAS USB driver, not BOT mass-storage.
This appears to be a "device-managed" SMR drive. Googling the serial number appears to confirm this, plus the disk indicates it supports ATA TRIM, but has no zone namespaces.
Note this disk is unpowered most of the time, I power it on and it immediately triggers my backups via a udev rule.

In terms of how this block device is configured on Linux:
USB UAS <-> dm-crypt (LUKS) <-> Btrfs

It was suggested to me in #fedora that the speed of writing to this drive may be the culprit for the OOM condition? hard to say, but I have been using this backup system longer than systemd-oomd seemed to have replaced the older facebook/oomd binary.
___

Storage Drive [btrfs send]: ST3000VN007-2E4166_Z73030Z2
___
This is where the data is coming from.
ATA (AHCI) <-> dm-crypt (LUKS) <-> Btrfs
___


Attachments:
sa_PSI.svg:
is a plot of the following command: `sadf -g -- -q PSI -s 08:10:00 > sa_PSI.svg`
unfortunately, the granularity is quite low, I wish I had a 1sec tick on it. When I attempt another backup, I'll make sure to have sar write to another datafile with 1sec intervals.

oomd_journalctl.txt
output of systemd-oomd since I noticed my backup script getting killed. what I find interesting here is the more recent ones, when I tried to replicate this, I see it killing random GNOME stuff in my user slice. I can confirm whatever it is killing, it's also killing the terminal that is running the sudo btrfs send/recv commands I'm using.

sys-backup_journalctl.txt
output of logging for this service. PLEASE NOTE, some of the failures were me making tweaks to my script because I noticed my backup failed once for the luks-backup-* uuid being mapped already which confused me. I now believe this occured because oomd killed my script and I didn't notice it til very recently.

sys-backup.sh / sys-backup.service
how my backups work. If you want the udev rule, I can give that as well?

Please ask if you need anything else. In the meantime, I'll try and build a better reproducible example and will likely turn systemd-oomd off for now.