Re: first it froze, now the (btrfs) root fs won't mount ...

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2019-10-25 13:05, Christian Pernegger wrote:
> P.P.S (sorry): Would using the DUP profile for metadata conceiveably
> be an extra line of defence in such cases (assuming the NVMe doesn't
> just eat the extra copies outright)? If so, is enabling it after fs
> creation safe and should system be DUP as well? Something like:
> # btrfs balance start -mconvert=dup [-sconvert=dup -f] $PATH
Yes, using the dup profile for metadata should help, provided it's not 
an issue with the rest of the system (if the metadata gets corrupted in 
memory, two bad copies will get written out).

On-line conversion is perfectly safe, and should not require explicit 
conversion of the system chunks (converting metadata will do that 
automatically).
> 
> Lastly ist $PATH just used to identify the fs, or does it act as a
> filter? IOW, can I use whatever or should it be run on the real root
> of the fs?
I think any path on the volume will work, though it's best to use it on 
an actual mount point so you know concretely what it's running on. Most 
of the ioctls are pretty forgiving like this, because it's not unusual 
to only have non-root subvolumes mounted from a volume.