view the rest of the comments
Steam Hardware
A place to discuss and support all Steam Hardware, including Steam Deck, Steam Machine, Steam Frame, and SteamOS in general.
As Lemmy doesn't have flairs yet, you can use these prefixes to indicate what type of post you have made, eg:
[Flair] My post title
The following is a list of suggested flairs:
[Deck] - Steam Deck related.
[Machine] - Steam Machine related.
[Frame] - Steam Frame related.
[Discussion] - General discussion.
[Help] - A request for help or support.
[News] - News about the deck.
[PSA] - Sharing important information.
[Game] - News / info about a game on the deck.
[Update] - An update to a previous post.
[Meta] - Discussion about this community.
If your post is only relevant to one hardware device (Deck/Machine/Frame/etc) please specify which one as part of the title or by using a device flair.
These are not enforced, but they are encouraged.
Rules:
- Follow the rules of Sopuli
- Posts must be related to Steam Hardware or Steam OS in an obvious way.
- No piracy, there are other communities for that.
- Discussion of emulators are allowed, but no discussion on how to illegally acquire ROMs.
- This is a place of civil discussion, no trolling.
- Have fun.
[This comment has been deleted by an automated system]
I'm interested to see that reported somewhere - the duperemove repo might be a good starting point as that's generally the standard BTRFS dedupe solution. I don't currently see any issues on the GitHub repo about corruption (or at least the last one was 7 years ago). Again, I'm not sure if a RAM bit flip could cause this during a dedupe. Just because you scrubbed, deduped, and scrubbed again doesn't mean there wasn't a bit flip during the dedupe.
As for
btrfs-checkvsfsck, there are just way fewer things that need to be repaired in BTRFS and ZFS because they are copy-on-write (ZFS doesn't even have afsckat all!). Because Ext4 is not Copy-On-Write, it's highly vulnerable to powerloss events, and anfsckis required to replay the journal when this happens. BTRFS and ZFS make atomic COW transactions and will never be in a state of corruption on power loss. The other part offsckis repairing the filesystem, which BTRFS and ZFS do throughscruband/or auto-heal on read instead. ZFS and BTRFS keep multiple copies of the filesystem metadata so that it can auto-repair itself while online.btrfs checkis not something that should be used lightly, and I've seen a lot of people just runbtrfs-check --repairexpecting the same behavior asfsck, then wonder why they ended up with a broken filesystem.