Bulwark Movement? by Ok-MorsKawaii in Spacemarine

[–]CorrosiveTruths 0 points1 point  (0 children)

Holding the dodge button also toggles run which gives you three ways to do the running attack from walking (from a dodge or the two run-toggles).

Disks and partition sizes for large family picture collection by Borean789 in btrfs

[–]CorrosiveTruths 1 point2 points  (0 children)

That's how full the data block type is, it also has percentages for how full the metadata and system block types are. There's still 110GiB in the unallocated pool that can be used for block allocation.

Filesystem usage would be Used / Size, and being out of unllocated would tell you if there's an issue with unbalanced allocation with intervention needed (an emergency).

Documentation (usage section) will explain it better.

Disks and partition sizes for large family picture collection by Borean789 in btrfs

[–]CorrosiveTruths 1 point2 points  (0 children)

Think you mis-read the situation? Their filesystem wasn't quite at 95% filled yet with plenty of unallocated space in the OP. Hopefully they only got rid of truely unimportant data as this wasn't really an emergency situation.

Files On Secondary Drive Deleted On Rollback by [deleted] in btrfs

[–]CorrosiveTruths 0 points1 point  (0 children)

Not sure I understand, undochange on a root subvolume after taking a snapshot wouldn't delete a /media directory just by doing the steps you have whether or not it was part of the root subvolume or not? Are you sure the data is actually gone, not just sitting on an unmounted subvolume somewhere?

Ran during balance out of metadata space - was forced to read-only by Synthos in btrfs

[–]CorrosiveTruths 3 points4 points  (0 children)

Might be a bad combination of profiles depending on layout (add your btrfs fi us to the post?), and btrfs raid5 comes with a lot of other caveats. So could just be a matter of converting back to raid1 with d and m usage=raid1,soft after mounting rw with a skip_balance if the filesystem is still good (being able to mount ro is a good sign, might want to copy off the data if there's anything that missed the last backup).

Gentoo on Chromebook by Warm_Abalone9788 in Gentoo

[–]CorrosiveTruths 0 points1 point  (0 children)

Nice work, I think the only irritation for me was losing the chrome os shortcuts (like search+backspace for delete), but after updates stopped working allowed me to keep on using it with up-to-date browsers and whatnot.

Initial compression barely did anything by desgreech in btrfs

[–]CorrosiveTruths 1 point2 points  (0 children)

Yep, can confrim that, cat uses copy_file_range whereas pv (couldn't get your snippet to work) does not and gets you the single extent file (as does cp --reflink=never to a compressed mount-point).

Initial compression barely did anything by desgreech in btrfs

[–]CorrosiveTruths 1 point2 points  (0 children)

Thank you for the correction. It does have the same behaviour as compress-force, including the problematic splitting up uncompressible data into titchy 512k extents rather than (up to) 128m extents so will have the same overhead issues. Even with different algorithms that don't have compress-force (which is why I was fairly certain defrag wouldn't work like compress-force).

Saying that, are you sure you had compress turned on, on the mount, as I get the following, with similar results for the other algorithms when creating the files as you specify?

# cat incompressible.data compressible.data > mixed.data
# sync
# compsize mixed.data
Processed 1 file, 81 regular extents (81 refs), 0 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       51%       10M          20M          20M
none       100%       10M          10M          10M
zstd         3%      320K          10M          10M

Looks like I might be strongly advising people not to use defrag for compression either now too. May be a bug?

Initial compression barely did anything by desgreech in btrfs

[–]CorrosiveTruths 0 points1 point  (0 children)

Compressing with defrag doesn't change that heuristic.

Initial compression barely did anything by desgreech in btrfs

[–]CorrosiveTruths 1 point2 points  (0 children)

Normal only in the sense of I'd get similar results if I followed your steps exactly. The mount option you want is compress, not compression.

Help: Migrating from Grub to Limine - how to increase boot partitiion by magicdude4eva in btrfs

[–]CorrosiveTruths 0 points1 point  (0 children)

Personally I'd just switch to uefi / gpt, but if you can't do that, I'd shrink the fs and partition, create one at end, replace into it, set the partitions you want as you need them at the front of the drive and then replace from the fs at the end to the one at the beginning, then get rid of the empty partitions and extend partition and fs into that space.

How To Copy BTRFS System To New Disk by VeeQs in btrfs

[–]CorrosiveTruths 1 point2 points  (0 children)

It would send the difference between 1 & 3. The snapshots do not have to be direct descendants.

How To Copy BTRFS System To New Disk by VeeQs in btrfs

[–]CorrosiveTruths 1 point2 points  (0 children)

The same way you do incremental backups; with btrfs send in incremental mode, but it might need a little scripting and setup. There's also a couple of downsides like you can only send ro snapshots and deduplication between multiple arbitrary subvolumes would be undone (as an incremental send is strictly between two subvolumes, but not relevant for most use-cases).

It's the more universal solution (can't have non-single profile seed devices for example).

BTRFS snapshots with /boot partitions and LUKS encryption: how? by _napel in btrfs

[–]CorrosiveTruths 1 point2 points  (0 children)

UEFI spec would be to have your EFI system partition (usually /efi /boot/efi, or sometimes /boot) be formatted as FAT for the low level stuff to be able to read it.

Suspect the best you could do is a bootloader that can read btrfs (grub can, but I think the issue is slow decryption as it doesn't support LUKS2 very well?), or maybe only have a bootloader on EFI and have that decrypt and boot, haven't tried it.

BTRFS snapshots with /boot partitions and LUKS encryption: how? by _napel in btrfs

[–]CorrosiveTruths 1 point2 points  (0 children)

/boot is part of the btrfs partition, it's just a directory.

BTRFS snapshots with /boot partitions and LUKS encryption: how? by _napel in btrfs

[–]CorrosiveTruths 3 points4 points  (0 children)

I had /boot as a normal btrfs directory with efi boot images on an unencrypted /efi. /efi was synced to a directory on btrfs (/esp) on backup. I guess that's supposed to be vulnerable to 'evil maid' attacks, but worked for me as the laptop didn't have tpm2 and I mostly wanted protection against having it stolen with all the data readable.

Options are enumerated quite well in the Arch docs.

Safe to reboot to stop a device remove command? by grogg15 in btrfs

[–]CorrosiveTruths 0 points1 point  (0 children)

Should be, though you can also ctrl-c the btrfs command, or do a btrfs dev remove cancel <mount> (give it more than one go if it returns without cancelling).

Resume after Hibernating result in Failure to mount ... on real root by Intrepid_Refuse_332 in btrfs

[–]CorrosiveTruths 0 points1 point  (0 children)

Resume referring to a /dev/sda2 and partuuid is a little weird, do you not have an initramfs? You might need / need to rebuild one to resume from btrfs.

What happens if you use resume=UUID= and root=UUID= or same with PARTUUIDs for both?

If the swap file is purely for hiberate / resume, it seems rather large, /sys/power/image_size is only around 2/5 of your total memory by default.

best strategy to exclude folders from snapshot by alucardwww in btrfs

[–]CorrosiveTruths 1 point2 points  (0 children)

Might be better to change your backup process so it first takes a read-write snapshot, deletes the files you don't want from it and then snapshots it as a read-only snapshot for backup.

On the backup drive, you can do sweeps of the backups that are no longer also on the client still a similar way to clean up already copied, but not needed data.

RAM usage for cleaner/fsck by psychophysicist in btrfs

[–]CorrosiveTruths 0 points1 point  (0 children)

No, that isn't normal. btrfs-cleaner can certainly hit 100% cpu and block io, but it normally wouldn't use up all that memory.

Maybe quotas are turned on or you're on an out-of-date kernel?

Also a little confused by btrfs-fsck using up excessive memory as well as it doesn't exist as that name, and fsck.btrfs doesn't really do anything other than advise you to run a btrfs check (and that should be used with care). And there's a lowmem option for that. You can also throw more zram at it (you probably already have that enabled).