I have a bunch of old documents on my computer separated in an "old documents" folder. Currently they are not compressed.
If I compress my "old documents" into a tar.zst archive, will I increase to decrease the probability of them becoming corrupted?

My home partition is using BTRFS if it matters. #BTRFS

"some performance improvements and one minor mount option update" are among the main #Btrfs changes merged for #Linux 6.16:

https://git.kernel.org/torvalds/c/5e82ed5ca4b510e0ff53af1e12e94e6aa1fe5a93

A few highlights:

Performance:

- extent buffer conversion to xarray gains throughput and runtime improvements on metadata heavy operations doing writeback (sample test shows +50% throughput, -33% runtime)

- extent io tree cleanups lead to performance improvements by avoiding unnecessary searches or repeated searches

- more efficient extent unpinning when committing transaction (estimated run time improvement 3-5%)

User visible changes:

- remove standalone mount option 'nologreplay', deprecated in 5.9, replacement is 'rescue=nologreplay'

- in scrub, update reporting, add back device stats message after detected errors (accidentally removed during recent refactoring)

Core:

- convert extent buffer radix tree to xarray

- continued preparations for large folios

Linux 6.16 will see more btrfs improvements

The btrfs filesystem in Linux 6.16 has undergone many improvements that make its performance faster than before. It has already been improved across Linux releases, but the upcoming version of Linux sees even more improvements to this filesystem. Any system that uses this filesystem can now benefit from those improvements.

The buffer conversion work underwent some throughput and runtime improvements for metadata heavy operations, backed by several commits in a pull request made to the 6.16 branch, such as “extent buffer conversion to xarray gains throughput and runtime improvements on metadata heavy operations doing writeback (sample test shows +50% throughput, -33% runtime).”

The tree cleanups have been improved to avoid repeated or unnecessary searches. This improves the I/O performance, should any operation rely on tree cleanups. As for committing transactions, the extent unpinning action has become more efficient than before, yielding a 3-5% performance improvement in runtime.

You can find more about this pull request by clicking on the below button:

Cover image credit.

Does anyone know how to recover a #btrfs raid0, where the disk is fine... It just lost the filesystem signature?

Hear me out.

The Great GitHub Nix Space Heist

I've just released Nothing but Nix, a GitHub Action that transforms cramped 20GB GitHub runners into 130GB #Nix powerhouses!

If you've ever hit thr no space left on device error when building #NixOS configs in CI, this one's for you.

This action:

• Creates a large #BTRFS volume from free space on /mnt
• Ruthlessly eliminates unnecessary packages in the background
• Dynamically expands your Nix store as space becomes available

The results? All my large configurations (workstations and servers) now build successfully in CI

Best of all, when I update systems, everything comes from my FlakeHub Cache with zero local compilation time Updates that used to require coffee breaks now happen in seconds!

Check out the full technical details on my blog

https://wimpysworld.com/posts/nothing-but-nix-github-actions/

Being both cheap and stubborn pays off sometimes #DevOps #GitHubActions

So, I'm facing a weird issue with my #fedora workstation. The filesystem goes "read-only" at random times and I dont know why. I've do a reboot to fix it. Do you have any idea about this and how to fix it ?

BtrFS completely sucks & i shall never again make the error of using it instead of ext4.

#Debian #trixie #kde has been really decent, however here's my biggest hesitation for desktop use (once it goes stable). I'm grateful that #LinuxMint's great #TimeShift app is now Debian-packaged.

I prospectively formatted my root partition as #BTRFS, wanting to make or revert snapshots in Timeshift. But alas, Debian's installer doesn't automagically create BTRFS subvolumes called "@" and "@home", as would be the case in Linux Mint's installer. Without those subvols being created, then Timeshift can't find those subvols, and complains. So no BTRFS snapshotting/restoring can be done in Timeshift.

Übrigens kann ich nur sehr dringend empfehlen, sich mit #ZFS zu beschäftigen. Das ist einfach endgeil, schon wegen der Snapshots. Aber auch Volumes, Quota, RAID, Dedup, Kompression… - alles eingebaut.
Mir fällt wirklich kein Grund für ext4 und Genossen ein.

#btrfs ist wohl ähnlich geil, das kenne ich aber nicht.

#Linux

I have a machine running #btrfs RAID1 with two SATA SSDs.

If I were to replace one of them with an NVMe SSD, would that improve performance, or would it be bottlenecked by the remaining SATA SSD?

(I know mdraid has a write-mostly mode, but I don't want to use it because (1) no bitrot correction and (2) I'd rather live with a performance hit than take my chances with a fragile tower of storage layers.)

Power on hours: 143724
Reallocated sector count: zero
#Btrfs total checksum mismatches: zero
Btrfs total read/write errors: f**king zero

Slow though they may be, hard disk drives are amazing. #SSD s are cool and all, but how often do you find one that's old enough to drive a car and still functioning perfectly?

#btrfs-progs 6.14 is out:

https://lore.kernel.org/all/20250326195854.23901-1-dsterba@suse.com/

https://github.com/kdave/btrfs-progs/releases/tag/v6.14

fuck my #btrfs partition just went read-only for no reason. smart tests ain’t failing but btrfs scrubs are

waiting for the data to get backupd and then just gonna reformat it with fucking xfs or ext4
#homelab

I migrated to a CoW file system 10 years ago and it never mooed in that entire time.