在 2018年4月4日，下午5:30，Miklos Szeredi <miklos@xxxxxxxxxx> 写道： > > On Sun, Apr 1, 2018 at 7:56 AM, cgxu519@xxxxxxx <cgxu519@xxxxxxx> wrote: >> 在 2018年3月29日，下午8:54，Miklos Szeredi <miklos@xxxxxxxxxx> 写道： >>> >>> On Sat, Jan 20, 2018 at 7:32 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >>>> On Sat, Jan 20, 2018 at 6:10 PM, Chengguang Xu <cgxu519@xxxxxxxxxx> wrote: >>>>> Inspired by encountering unexpected write error with >>>>> error code -EXDEV when upperdir and workdir having >>>>> different project quotas. The reason of the error is >>>>> project quota asks files in it strictly inherit >>>>> project id of it’s own, so rename/link operations >>>>> between those directories will fail and it may cause >>>>> failure during copy-up/index-link operations in overlayfs. >>>>> >>>>> So if upper filesystem supports O_TMPFILE, try to check >>>>> link ability between upperdir and workdir and if check >>>>> fails, print a proper warning message to indicate potential >>>>> possibility of write failure. >>>>> >>>>> The failure of the check does not directly lead to >>>>> read-only mounting because in some use cases may only >>>>> write to upperdir and do not modify anything in lowerdirs. >>> >>> Thinking about a bit more: this assumes that mounter has create >>> permission under upper layer root. That assumption would be true in >>> ordinary setups. But if we break that assumption and deny create in >>> the root of the upper layer, we could still have a perfectly working >>> setup (as long as there's no need to copy-up anything in that >>> directory). >> >> Isn’t it similar to the check which upperdir and workdir must be in same filesystem? >> If we set project quota then the related directories will behave like sub-filesystem. > > > I agree with that. > > What I'm saying is that your implementation may give a false positive > (i.e. warning on an otherwise perfectly working setup). I think we can check error code(-EXDEV) to filter out the case of false positive, if it makes sense, I will send revised patch. > > Worse yet, it may change the result of the tmpfile test in such a > case, which is a regression. Yes, it’s better to keep tmpfile test as it is. > > So I think the implementation needs to be rethought. Thanks, Chengguang. -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
