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). Worse yet, it may change the result of the tmpfile test in such a case, which is a regression. So I think the implementation needs to be rethought. Thanks, Miklos > > > Thanks, > Chengguang. > > >> >> So I'm not sure it's worth adding code for a check that is of dubious value. >> >> Thanks, >> Miklos >> -- >> 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 > -- 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
