SDB Talk:BTRFS

Should a repaired BTRFS volume be trusted?

Although I haven't done even a bit of research whether advised anywhere when doing a BTRFS repair to recover the volume, it's been my experience that anytime you recover data from a file system or database (there are similarities), when a "repair" or similar "recover" utility is used, the overall schema should be considered possibly damaged and not to be trusted... Therefor the general recommendation is to create a new, empty and generic "container" (file system, database app, whatever) and load the recovered data into it. When the copied data's integrity has been verified, then the original instance can be deleted thereby recovering space.

Understandably, these extra steps greatly complicates the entire process but I wonder if this should still be a recommendation if not a required continuation of what is described.
Tsu2 06 February 2020

Recommend to make device snapshot before attempting to repair FS?

Lot's of things can go wrong when trying to repair a FS. If some spare space is available it is a good idea to first make a snapshot of the device(s) holding the FS (not to be confused with a btrfs snapshot), e.g. as described in https://gist.github.com/jowagner/b36024636140ddf453c12eaf6e590b5d . Add a paragraph at the start of the repair section to recommend this? Jowagner (talk) 15:34, 4 November 2021 (UTC)

New section on configuring maintenance jobs

Discuss common tasks involving /etc/sysconfig/btrfsmaintenance, e.g. adding a manually created filesystem to BTRFS_SCRUB_MOUNTPOINTS. Related: https://en.opensuse.org/SDB:Disable_btrfsmaintenance Jowagner (talk) 16:17, 4 November 2021 (UTC)