Correction:
- fermer le client torrent.
- créer un répertoire vide, le mettre en NOCOW (chattr +C nouveau)
- copier l'ancien répertoire dedans (cp -r -v --reflink=never ancien nouveau) (sinon ça gardera les blocs de données qui sont déjà en mode CoW)

I do think that one thing getting glossed over in the bcachefs kerfuffle is that the guy is probably right about #btrfs having remaining reliablity problems - granted I didn't go digging that hard, but I haven't found anywhere where the ~5 year old papers on btrfs becoming unrecoverable in many more underlying data corruption situations than ext4 were addressed, and certainly not with "many of those cases have been fixed."

2/3 Topics #EU_OS needs help with:

1) What is the best way to backup user data for Linux EU OS users? https://gitlab.com/eu-os/eu-os.gitlab.io/-/issues/46 #borgbackup #btrfsbk #btrfs#nextcloud

2) How can unattended deployment with #foreman look like during pilot stage (thus without reconfiguring the network/DHCP yet)? https://gitlab.com/eu-os/eu-os.gitlab.io/-/issues/39 #foreman

3) How can a modern VPN provide extra security for people in home offices or on business trips? https://gitlab.com/eu-os/eu-os.gitlab.io/-/issues/47 #tailscale #headscale #rosenpass #wireguard #openvpn

#btrfs would be a lot better if it *handled* errors rather than detecting them (which it's great at) and then blowing the fuck up.

anybody know if #btrfs has improved this situation with regard to filesystem recoverability after medium errors common on consumer SSDs?

https://www.usenix.org/system/files/atc19-jaffer.pdf

anybody know if #btrfs has improved this situation with regard to filesystem recoverability after medium errors common on consumer SSDs?

https://www.usenix.org/system/files/atc19-jaffer.pdf

So after multiple power losses yesterday; and multiple instances of btrfs log tree corruption yesterday. AND swapping out kernels and simulating power failures this morning. I've got a lot of anecdotal evidence that Liquorix Kernel 6.15.5 has something odd going on with how either the timing of it writing it's log tree on my NVME, or it's failing to flush the write of the log tree on my NVME.

Lets just say, im going back to openSUSE's vanilla kernel for the rest of my openSUSE adventure. #linux #btrfs#openSUSE #Liquorix

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

In snac on an ancient Raspberry Pi news, I switched from XFS to Btrfs and my memory pressure issues are now a thing of the past. As a bonus I can use snapshots for backups instead of taring up the many small files that snac generates (it has no traditional database).

I tried tuning various parameters but after some reading came to the conclusion that lots of small files with very little RAM is about the worst case scenario for XFS.

#linux #snac #btrfs

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