#Btrfs-progs 6.15 is out:
https://github.com/kdave/btrfs-progs/releases/tag/v6.15
https://lore.kernel.org/all/20250623144659.26266-1-dsterba@suse.com/
"'This is more of a bugfix release with a few feature updates.
Changelog:
* mkfs: new option --inode-flags to specify flags/attributes for inodes/directories/subvolumes
[…]
* rescue: add new command fix-data-checksum, selectively fix or find mismatching checksums
[…]"'
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:
Learn moreDoes anyone know how to recover a #btrfs raid0, where the disk is fine... It just lost the filesystem signature?
Hear me out.
@tokyo_0 @abhijith @fossunleashed @llutz @zenbrowser (5/5)
It can't be a fluke right if it happened twice.
@tokyo_0 @abhijith @fossunleashed @llutz @zenbrowser (4/5)
But, the moment I opened Zen Browser suddenly the filesystem went read-only. Coincidence, I think not. This also happened when I was offline. I opened Zen it showed me the webpage, all good. I reloaded it, it showed me the classic thing "something unexpected happened". All good. But when I closed the #browser, suddenly the FS went read-only.
@tokyo_0 @abhijith @fossunleashed @llutz @zenbrowser (3/5)
To check the memory I used `sudo memtester 1024 5`. And EVERYTHING was fine. Even when I turned on the #wifi nothing changed. I opened the #GnomeSoftwareCenter app, I also opened #firefox to browse #youtube and log in to this instance. Everything was fine.
@tokyo_0 @abhijith @fossunleashed @llutz @zenbrowser (2/5)
So, today morning I opened the laptop with #wifi turned off and checked the system. It was going alright. The filesystem was behaving normally like it should. I also double-checked it using `mount | grep "btrfs"` and `fastfetch`. To check the nvme drive, I used `sudo smartctl --xall /dev/nvme0n1p3` + the diagnostics tool in the bios menu.
@tokyo_0 @abhijith @fossunleashed
@llutz (1/5)
I now think that I can pinpoint the problem of the filesystem going read-only and it's (probably) neither the FS itself nor the nvme drive. And definitely not the RAM.
The problem is a single app that's causing this or that's what I found and its the @zenbrowser browser.
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:
/mnt
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