Gabriel de Perthuis <g2p.code@xxxxxxxxx> schrieb: > There's no deep reason read-only snapshots should keep their storage > immutable, they can be affected by raid rebalancing for example. Sounds logical, and good... > The current bedup restriction comes from the clone call; Mark Fasheh's > dedup ioctl[3] appears to be fine with snapshots. The bedup integration > (in a branch) is a work in progress at the moment. I need to fix a scan > bug, tweak parameters for the latest kernel dedup patch, remove a lot of > logic that is now unnecessary, and figure out the compatibility story. I'd be eager to test as soon as the patches arrived in the official kernel distribution. Do you plan to support deduplication on a finer grained basis than file level? As an example, in the end it could be interesting to deduplicate 1M blocks of huge files. Backups of VM images come to my mind as a good candidate. While my current backup script[1] takes care of this by using "rsync --inplace" it won't consider files moved between two backup cycles. This is the main purpose I'm using bedup for on my backup drive. Maybe you could define another cutoff value to consider huge files for block-level deduplication? Regards, Kai [1]: https://gist.github.com/kakra/5520370 -- 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
