> You didn't use an INCOPMAT option for this so you need to deal with a user > mounting the file system with an older kernel or even forgetting to use mount -o > dedup. Otherwise your dedup tree will become out of date and you could corrupt > peoples data. So if you aren't going to use an INCOMPAT flag you need to at > least use a COMPAT flag so we know the option has been used at all and then you > need to have a mechanism to know if you need to invalidate the hash tree. > > Users are also going to make the mistake of thinking dedup will make their > workload awesome, and when it doesn't they need a way to turn it off. If you do > an INCOMPAT option then you need to have a way to delete the hash tree and unset > the INCOMPAT flag. If you do the COMPAT route then you get this for free since > the user just needs to stop using -o dedup, but you'll probably also want to > provide a mechanism to delete the tree to free up space. Thanks, > > Josef I made a few mistakes on this, yeah I should also provide a dedup disable way and I'm going to use INCOMPAT. But forgetting to use mount -o dedup will not get dedup tree to be out of date, because dedup tree is loaded if we have it, no matter whether using 'mount -o dedup'. Thanks for the nice reminder, Josef :) thanks, liubo -- 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
