Btrfs, Restic, Symlinks, ZRAM, SME/TSME, Zstd, Ddrescue

1. Btrfs & SMR - I'm very happy how quickly the backup updates are being written to the disk. This is clearly a quite good fit, because btrfs tends to allocate together new writes, which is very important so that too many shingle stacks do not get modified on the SMR drive, as well as keeping the metadata compactly together. Ext4 caused a huge amount of metadata updates and data scattering around the drive (and shingle stacks) when updating a large number of 8 MiB files in different directories.

2. Restic + ext4 + SMR = bad combination. Why? Restic uses lots of small files (relatively for large data sets, ~16 MiB) and directories (256+ directories), and ext4 groups (and spreads) data per directory, scattering data causing significant SMR shingle stack rewrites and write amplification -> slow down. Btrfs performs a lot better in this case.

3. Removing dangling (broken) symlinks, simple right? I had a good old script which used find -xtype l. Yet it wasn't working. I did lots of debugging, and managed to baffle all AI models as well. They didn't know why it's happening. When getting frustrated enough, I asked them to provide alternate solutions. Finally, the ultimate working solution is to use readlink -f to get the target and then verify that IT exists. And if not, then remove it. Phew... The symlinks Utility and Cross-Filesystem Symlinks - No, the symlinks utility does not detect or change dangling links across filesystems. This is explicitly mentioned as a limitation in the BUGS section of the manual: symlinks does not recurse or change links across filesystems. While the utility does identify links classified as "other_fs" (those whose target resides on a different filesystem), it has limited functionality when working with them.

4. It seems that quite many Windows SysAdmins don't know Symbolic Links at all, and get seriously confused when encountering one. Uh oh.

5. Nice, it's possible to use ZRAM with writeback to disk. But I just wish tools like zswap would directly allow it by flipping a single option. Ref: linux, compressed, swap, zram, CONFIG_ZRAM_WRITEBACK.

6. pSLC SSD - I didn't know that pSLC stands for pseudo-Single Level Cell. They just use TLC or QLC flash with a controller that basically saves 0 or 1 into the cell. Allowing quicker operation and using more leaky and worn-out cells to be read reliably.

7. System AGESA update including UEFI generally called motherboard firmware, caused the system to lose all settings. Sigh. I'm sure that 99.99% of users do not properly photograph or take notes on all of the motherboard settings before the update. Also, TPM data was lost, which CAN be a huge problem. Yet of course I had all the necessary keys properly backed up in multiple locations.

8. Memory Encryption: Tested using a few test systems and options SME and TSME with an AMD system and with Intel TME, both with Linux. I didn't have a suitable easy-to-run SEV / TME-MK operating system, because Qubes OS doesn't support it, so I skipped that part. Nor hardware with SEV-SNP just to play with. What summer vacation fun, haha.

9. One system used to repeatedly compress very similar data independently. I improved the compression efficiency radically by adding a precomputed Zstd dictionary to the process. Now messages that earlier were tens of kilobytes are compressed in less than one kilobyte usually, because it's just all references to almost identical data repeatedly.

10. Found out that SMART data self-test is suspended during power saving and resumes after it. But it doesn't override power-saving; if the drive spins down, then the test is suspended until the drive is powered up again and on idle, then it resumes. Nice work!

11. I used ddrescue (gddrescue) - https://en.wikipedia.org/wiki/Ddrescue - (@ Wikipedia) to recover a few broken SSDs. I like the program. Usually, I'm very annoyed about badly designed and implemented programs. But in this case, I was truly delighted how smartly the program behaves with standard settings... I should say pretty awesome program. Thank you for that! And now it's honest appreciation, not frustrated sarcasm. 99.97% data recovered. It was never found out what data (if any) the corrupted last 0.03% contained, but due to resource and cost constraints, the damaged copy was used "as it is" without rebuilding the system. Yeah, I wouldn't personally have done that. But sometimes time and money are more important than perfection.

2026-07-05