Jan Kara <jack@xxxxxxx> writes: > Hi, > >> PROJECT_ISOLATION >> This feature allows to create an isolated project subtrees. >> Isolation means what: >> 1) directory subtree has no common inodes (no hadlinks across subtrees) >> 2) All descendants belongs to the same subtree. >> >> Project subtree's isolation assumptions: >> 1)Inode can not belongs to different subtree trees >> Otherwise changes in one subtree result in changes in other subtree >> which contradict to isolation criteria. > Just a curious question: > Do you really need this subtree separation in your envisioned containers > usecase? Because there I imagine you have one project_id per container, > containers form disjoint subtrees (at least their writeable parts) and > each file & directory has this project_id set and you forbid to manipulate > project id's from inside the container (otherwise you'd have problems with > enforcing quota limits I guess). > > And when project_id is a per-inode property, quota has no problems with it > (is well defined) even without subtree separation. So is this subtree > separation really needed? You right containers dealt with with only one subtree so bindmount is sufficient for all container's like sulutions. I've done this isolation part after long discussion with Dave Chinner He give some examples there fs-specific (not mount ones) isolation is useful. Most obvious usage example of project which has several trees. He intend that this feature is used by XFS users. But this feature attract most complains from reviewers, and i'll drop it if will be necessary to merge the project-id quota. > > Honza -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
