2

[Linux Mint 20.1, 16GB RAM, 16GB swap]

I recently converted my system - root and backup partitions - to BTRFS. I've been experimenting with archiving some of root's snapshots to my backup drive, but the memory usage of the following commands brought my system to its knees:

btrfs send /.snapshots/98/snapshot | btrfs receive /media/backups/@root/.snapshots/98

This command sucked up nearly 20 GB of RAM, completely freezing my system a couple of times in the process. My root partition is using about 11 GB, not including snapshots.

My next test was using the same command within a script (original reason was to test systemd-run and setting memory limits), like this:

#!/usr/bin/fish

btrfs send /.snapshots/98/snapshot | btrfs receive /media/backups/@root/.snapshots/98

Running this script used a grand total of 8 MB and was 4x faster. Just to be sure I was running in the same testing environment, I made sure that the original backup snapshot was deleted and committed (btrfs subvol delete -Cv). I also ran the same tests with bash, got the same results.

UPDATE: just to make each test the same, I ran both again - in fish and bash - using /usr/bin/btrfs instead of my alias (to sudo btrfs). The results were the same.

UPDATE #2: my previous update was in error.

Improve this question
11
  • have you tried again the first one after running the script? to see if something else changed ? On the top of my head I could maybe see the influence of running in an interactive shell for the first one... so maybe there are a different environment (locale? TERM and somehow btrfs goes through terminal functions?) .. but all unlikely. You could try: strace-ing those process and compare (... but you'll need lots of space to store strace output). and compare: printf "%s\n" "$PATH" in both ? to see if you start the same command... (or which btrfs, or type -all btrfs )
    – Olivier Dulac
    Feb 1, 2021 at 5:49
  • I will test this again after my next reboot, to make sure that I have a clean environment.
    – ajgringo619
    Feb 1, 2021 at 5:57
  • I meant: if you executed the script after the shell one, maybe something occured that made the 2nd pass faster? so just try just after the bash one and see if the latter try is also faster?
    – Olivier Dulac
    Feb 1, 2021 at 6:01
  • I tried it in reverse - script first, then shell - and the results were the same. I've incorporated the script into my python backup program; if that works, then I'm not going to worry about it.
    – ajgringo619
    Feb 1, 2021 at 23:59
  • 1
    In fish shell this could happen if btrfs is a function, which would need to buffer its output. Does type btrfs show something other than just an executable path?
    – ridiculous_fish
    Feb 2, 2021 at 3:50

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.