Rich Freeman <r-bt...@thefreemanclan.net> schrieb: > On Sun, Mar 29, 2015 at 7:43 AM, Kai Krakow <hurikha...@gmail.com> wrote: >> >> With the planned performance improvements, I'm guessing the best way will >> become mounting the root subvolume (subvolid 0) and letting duperemove >> work on that as a whole - including crossing all fs boundaries. >> > > Why cross filesystem boundaries by default? If you scan from the root > subvolume you're guanteed to traverse every file on the filesystem > (which is all that can be deduped) without crossing any filesystem > boundaries. Even if you have btrfs on non-btrfs on btrfs there must > be some other path that reaches the same files when scanning from > subvolid 0.
Yes, the chosen "default" is probably not the best for this kind of utility. But I suppose it follows the principle of least surprise. At least every utility I'm daily using (like find) follows this default route. By the way, I wrote "default" because one should keep in mind that it is not recursive by default (and thus crossing the boundary wouldn't even apply in the default configuration) which only strengthens my point for the principle of least surprise. And I'd leave that open for discussion here to change the default, all I suggested was that duperemove should not try to become smart about it as the only choice (behavior will be undefined otherwise when deploying this on a vast amount of individually configured systems). I could image that there was a cmdline option to make it smart. The idea for subvolid 0: It is just pure intention how I would use it for my personal purpose. By no means this should be in any default deployments. -- Replies to list only preferred. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
