I'm working several years with btrfs now and I like it. Some days ago I made a mistake. I did notice it when it happened but I'm pretty sure it was an rsync with delete option and bad parametrization.
Subvolume structure was:
Level 1 (or based on output below level 5)
ROOT
snapshots
sync1
sync2
Now it loks like this when mounting the volume to btrfs - which means snapshots and ROOT is not visible anymore as folder but still existing.
sync1
sync2
The subvolume structure is still existing and also the data in the volumes like ROOT or snapshots. Only the hierarchical representation in folders is missing. So basically it would be possible to get the structure back with several mount points. But I'm not sure if this would cause other problems.
ID 256 gen 3240889 top level 5 path ROOT
ID 257 gen 3222668 top level 5 path sync1
ID 258 gen 3222669 top level 5 path sync2
ID 259 gen 1254199 top level 5 path snapshots
ID 260 gen 3240773 top level 259 path snapshots/ROOT_snaps
ID 261 gen 3222669 top level 259 path snapshots/sync1_snaps
ID 262 gen 3222670 top level 259 path snapshots/sync2_snaps
ID 13559 gen 460212 top level 260 path snapshots/ROOT_snaps/4332/snapshot
ID 13560 gen 460212 top level 261 path snapshots/sync1_snaps/3849/snapshot
ID 13561 gen 460213 top level 262 path snapshots/sync2_snaps/2924/snapshot
...
After the mistake the subvolumes still exist but only the ohnes which have been excluded by the rsync are still shown as folders when mounted on top level. The others are only acessible via directly mounting them. In past it was also possible to see the whole subvolume / folder hierarchy via mounting the volume e.g. to a folder like btrfs.
The folders which are based on subvolumes should not be deletable or at least there should be a mount option to avoid it. Only the deletion of the subvolume byself should remove the folder when the toplevel volume is mounted (but that should be the same in the whole folder tree with subvolumes).
Current results im my case: no errors with btrfsck. 4 errors with scrub which are not correctable. I will maybe give btrfs rescue a try but I don't see a direct connection between options and this problem.
I'm working several years with btrfs now and I like it. Some days ago I made a mistake. I did notice it when it happened but I'm pretty sure it was an rsync with delete option and bad parametrization.
Subvolume structure was:
Level 1 (or based on output below level 5) ROOT snapshots sync1 sync2
Now it loks like this when mounting the volume to btrfs - which means snapshots and ROOT is not visible anymore as folder but still existing. sync1 sync2
The subvolume structure is still existing and also the data in the volumes like ROOT or snapshots. Only the hierarchical representation in folders is missing. So basically it would be possible to get the structure back with several mount points. But I'm not sure if this would cause other problems. ID 256 gen 3240889 top level 5 path ROOT ID 257 gen 3222668 top level 5 path sync1 ID 258 gen 3222669 top level 5 path sync2 ID 259 gen 1254199 top level 5 path snapshots ID 260 gen 3240773 top level 259 path snapshots/ROOT_snaps ID 261 gen 3222669 top level 259 path snapshots/sync1_snaps ID 262 gen 3222670 top level 259 path snapshots/sync2_snaps ID 13559 gen 460212 top level 260 path snapshots/ROOT_snaps/4332/snapshot ID 13560 gen 460212 top level 261 path snapshots/sync1_snaps/3849/snapshot ID 13561 gen 460213 top level 262 path snapshots/sync2_snaps/2924/snapshot ...
After the mistake the subvolumes still exist but only the ohnes which have been excluded by the rsync are still shown as folders when mounted on top level. The others are only acessible via directly mounting them. In past it was also possible to see the whole subvolume / folder hierarchy via mounting the volume e.g. to a folder like btrfs.
The folders which are based on subvolumes should not be deletable or at least there should be a mount option to avoid it. Only the deletion of the subvolume byself should remove the folder when the toplevel volume is mounted (but that should be the same in the whole folder tree with subvolumes).
Current results im my case: no errors with btrfsck. 4 errors with scrub which are not correctable. I will maybe give btrfs rescue a try but I don't see a direct connection between options and this problem.