Doesn't BTRFS use copy-on-write technology?
As far as I understand, creating a snapshot does not involve any copying of data and as such is similar to a restore point marker.Correct.
When mounting a snapshot or subvolume, any file system changes are recorded in metadata, which contains information about what data blocks were changed and the differential data itself.Correct.
Snapshot and subvolumes are independent files systems and have their own copy of a B-tree.Incorrect. Snapshots and subvolumes are not independent, nor do they have their own B-tree. They're stored in the same B-tree as the rest of the btrfs filesystem.
When modifying data, such actions are again recorded and affect only the currently mounted volume. But unless data was modified, there is still only one copy of a data block on disk and hence the snapshot won't help if such data is lost due to a bad disk block or disk error.Correct, but removing the original data doesn't impact the snapshot (assuming there is no bad block/disk error). Hence, there is no concept of a "parent" snapshot in btrfs -- once you've created a snapshot, it exists all by itself, as it's own entity. You can mount a snapshot/subvolume as well. In fact, you can mount multiple instances of the same btrfs filesystem using different subvolumes and it's all the same filesystem.
SAN and virtualization products use similar snapshot technologies. As far as I'm aware, this is great for undoing data changes by deleting snapshots or mounting different versions of subvolumes, but its not a solution for full data recovery and not a suitable solution to recover Oracle databases.This is also correct.
Rob wrote:Hmm, ok. Will look that up and validate this with the Oracle Database guys. Thanks for the pointer.
Look for the Oracle 11gR2 on Linux certification document. I don't have the number handy (on my iPad at home, feeding kids), but btrfs was listed on there as a supported filesystem.