On Fri, 20 Mar 2015 04:18:38 AM Duncan wrote: > If cp --reflink=auto was the default, it'd "just work", making a reflink > where possible, falling back to a normal copy where not possible to > reflink. > > However, I'd be wary of such a change, because admins are used to cp > creating a separate copy which may well be intended as a backup, guarding > against I/O errors on the original. Btrfs does do checksum checking to > ensure validity, but if that fails, do you really want it failing for > BOTH copies, including the one the admin made specifically to AVOID such If you have a second copy on the same filesystem then an error on any of the metadata that is a parent will corrupt both. EG if you have 2 copies under your home directory then a directory error for /, /home, or /home/$USER will make both copies unavailable. Also any errors on superblocks or other essential filesystem metadata risks losing both copies. If BTRFS was to adopt something equivalent to the ZFS "copies=" feature then the sysadmin could specify that certain subtrees would have extra copies of data AND each metadata block would have 1 more copy than the data blocks it refers to. In conclusion I think that the ZFS copies= feature is the correct solution to this problem. Until/unless the BFTRFS developers copy that design concept the thing to do if you want backups on the same storage hardware is to copy the data to a filesystem on a different partition - the NetApp research shows that disk read errors tend to be correlated by location on disk. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
