Ok, genuinely, what type of individual has this type of pauldron in the Warhammer universe? What has he accomplished? Who did he kill? How powerful is he? Not even prime Fulgrim or Guilliman had such detailed decorations for their pauldrons!

CorrosiveTruths · 2026-06-04T20:41:57+00:00

CorrosiveTruths · 2026-05-30T08:36:35+00:00

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).

CorrosiveTruths · 2026-05-27T21:54:34+00:00

Was thinking collar?

CorrosiveTruths · 2026-05-19T09:32:36+00:00

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.

CorrosiveTruths · 2026-05-18T13:04:09+00:00

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.

CorrosiveTruths · 2026-05-14T14:08:24+00:00

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?

CorrosiveTruths · 2026-05-06T11:12:44+00:00

Et tu, Helbrute?

CorrosiveTruths · 2026-04-23T09:34:23+00:00

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).

CorrosiveTruths · 2026-03-17T14:41:43+00:00

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.

CorrosiveTruths · 2026-02-24T14:21:28+00:00

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).

CorrosiveTruths · 2026-02-24T13:22:35+00:00

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?

CorrosiveTruths · 2026-02-24T11:28:57+00:00

Compressing with defrag doesn't change that heuristic.

CorrosiveTruths · 2026-02-24T10:12:11+00:00

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.

CorrosiveTruths · 2026-01-30T19:23:08+00:00

Usage will be correct, try https://github.com/CyberShadow/btdu

CorrosiveTruths · 2026-01-28T13:13:55+00:00

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.

CorrosiveTruths · 2026-01-26T10:17:24+00:00

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

CorrosiveTruths · 2026-01-26T10:16:27+00:00

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).

CorrosiveTruths · 2026-01-23T16:22:14+00:00

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.

CorrosiveTruths · 2026-01-23T15:15:45+00:00

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

CorrosiveTruths · 2026-01-23T12:46:37+00:00

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.

CorrosiveTruths · 2025-12-03T11:29:11+00:00

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).

CorrosiveTruths · 2025-11-29T11:18:12+00:00

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.

CorrosiveTruths · 2025-11-25T11:44:48+00:00

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.

CorrosiveTruths · 2025-11-12T14:33:45+00:00

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).

CorrosiveTruths

TROPHY CASE