[ ... ] >>>> It is beneficial to not have snapshots in-place. With a local >>>> directory of snapshots, [ ... ] Indeed and there is a fair description of some options for subvolume nesting policies here which may be interesting to the original poster: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout It is unsurprising to me that there are tradeoffs involved in every choice. I find the "Flat" layout particularly desirable. >>> Netapp snapshots are invisible for tools doing opendir()/ >>> readdir() One could simulate this with symlinks for the >>> snapshot directory: store the snapshot elsewhere (not inplace) >>> and create a symlink to it, in every directory. More precisely in every subvolume root directory. >>> My users want the snapshots locally in a .snapshot >>> subdirectory. Btrfs snapshots can only be done for a whole subvolume. Subvolumes and snapshots can be created by users, but too many snapshots (see below) can cause trouble. For somewhat good reasons subvolumes including snapshots cannot be deleted by users though unless mount option 'user_subvol_rm_allowed' is used. >>> Because Netapp do it this way - for at least 20 years and we >>> have a multi-PB Netapp storage environment. No chance to change >>> this. Send patches :-). > Not only du works recursivly, but also find and with option > also ls, grep, etc. Note also that subvolume root directory inodes are indeed root directory inodes so they can be 'mount'ed and therefore the transition from a subvolume into a contained subvolume can be detected at the mountpoint. So 'find' has the '-xdev' option and 'du' has the '-x' options and so similarly nearly all other tools, so perhaps someone expects that to happen :-). > And it would require a bind mount for EVERY directory. There can > be hundreds... thousends! Assumptions that all Btrfs features such as snapshots are infinitely scalable at no cost may be optimistic: https://btrfs.wiki.kernel.org/index.php/Gotchas#Having_many_subvolumes_can_be_very_slow -- 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
