Frage an die Schwarmintelligenz: Gibt es bei #btrfs interne Statistiken die verwendet werden können, um die größten "Speicherfresser" zu finden? Ohne du -sk machen zu müssen was über jede einzelne Datei geht?
Frage an die Schwarmintelligenz: Gibt es bei #btrfs interne Statistiken die verwendet werden können, um die größten "Speicherfresser" zu finden? Ohne du -sk machen zu müssen was über jede einzelne Datei geht?
Idem ici il y a 2 mois : les système de fichiers bascule d'un coup en mode "lecture seule" et au reboot, impossible de monter le /home .
Le #btrfs rescue zero-log faisait le job pour le reboot mais le système retombait toujours en mode "lecture seule" après une action qui nécessite d'écrire dans /tmp.
Par contre moi j'avais bien des blocks corrompus (j'sais pas comment c'est arrivé)
J'ai fini par reformater le disque !
Tiens, premier souci avec #BTRFS depuis genre 10 ans.
Après un crash de mon PC au réveil de veille + extinction sauvage.
Au redémarrage échec de montage de / avec “can't read superblock” Oh comme ça pue !
- btrfs rescue super-recover <device> : “All supers are valid, no need to recover”
- btrfs check <device>: “...no error found”
Et pourtant impossible de le monter, sauf avec “-o ro,norecover”
- btrfs rescue zero-log <device>
Des personnes par ici ont de l'expérience avec l'utilisation combinée de #bcache et #btrfs ?
Vous auriez des retours d'expérience et conseils / recommandations ?
C'est pertinent comme cache en lecture (surtout) si on a une asymétrie du style 500Go de SSD pour >10To de HDD ?
Il me semble que pour mon cas d'usage c'est la lecture aléatoire qui est la plus pénalisante.
1/3
"Error removing device ... Input/output error"
Yeah, thanks #BTRFS, that's why I'm trying to remove it.
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
Back on #BTRFS after #XFS / #GRUB caused boot failures. First it would work on about every 6th attempt, now it didn't work at all. I'll just mount it with nodatacow, that should give Good Enough TM performance.
Also set up a watchdog a delayed reboot after panic, just to be safe. Should probably also set up a GRUB fallback in case a #NixOS update breaks booting again...
@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 #gnomesoftware 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.
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 ?
Bcachefs, Btrfs, EXT4, F2FS & XFS File-System Performance On Linux 6.15
https://www.phoronix.com/review/linux-615-filesystems
Discussions: https://discu.eu/q/https://www.phoronix.com/review/linux-615-filesystems
Quickbeam (a Mac Mini on a shelf in my home office) has been on #btrfs for about three months now. I was vary of it initially, but it is working out nicely so far.
And if it falls apart: no worries, I have backups.
I still worry what will happen if it falls apart, though, because there aren't many other filesystems I'd be happy with. I'm not going to use ZFS while it remains an external module, and then the only other option is LVM + ext4 or xfs (I want snapshots), and LVM+whatever would complicate my backup strategy somewhat.
So here's hoping that btrfs continues to work fine.
So, I’ve basically reinstalled the system from a USB drive and am now restoring #backups. Luckily, I backed up all the #Dotfiles and configurations and so the #desktop is behaving as before, which is a big relief. On the up side, it’s booting a lot faster and the #disk has #btrfs #partition, rather than #Ext4.
Je dois changer de disque (je remplace mon SATA 350 Go par un SSD Crucial 1 To : https://www.debian-fr.org/t/migration-sur-ssd/91101 ) et je voulais partir sur du LVM/BTRFS.
On me dit que LVM/BTRFS c'est me compliquer la vie pour rien, sur une machine d'usage ordinaire ext4 suffit largement et en tous cas BTRFS fait double emploi avec LVM.
Un avis ceux qui utilisent #BTRFS ?