this post was submitted on 13 Sep 2023
85 points (92.1% liked)
Steam Deck
14892 readers
431 users here now
A place to discuss and support all things Steam Deck.
Replacement for r/steamdeck_linux.
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:
[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.
Some more Steam Deck specific flairs:
[Boot Screen] - Custom boot screens/videos.
[Selling] - If you are selling your deck.
These are not enforced, but they are encouraged.
Rules:
- Follow the rules of Sopuli
- Posts must be related to the Steam Deck 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.
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
[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-check
vsfsck
, 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 afsck
at all!). Because Ext4 is not Copy-On-Write, it's highly vulnerable to powerloss events, and anfsck
is 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 offsck
is repairing the filesystem, which BTRFS and ZFS do throughscrub
and/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 check
is not something that should be used lightly, and I've seen a lot of people just runbtrfs-check --repair
expecting the same behavior asfsck
, then wonder why they ended up with a broken filesystem.