On Fri, Apr 7, 2017 at 12:43 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Thu, Apr 6, 2017 at 6:46 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> Yes, but do you think we should delay consistent_fd until we have a full >> solution for constant_ino? >> Do you think it is acceptable to fix only stat (to return lower ino) and leave >> readdir d_ino for later? > > I don't know, because, as we discussed previously, these are really > luxury bugs, and there's no push for either from real use cases. So > I'd add fixes in the order of becoming the obviously right fix. I > think we are closer to getting the constant ino resolved properly than > consistent fd. > > I really want to look into sharing pages between clones. That makes sense. I also really want you to look into sharing pages between clone ;-) Keep in mind that even though you are looking into sharing pages, I think it may be still safe to propagate modification to readers lazily. What I mean (and I may very well be talking nonsense) is that if you choose to modify the f_mapping->host of readers some time after copy up, maybe its enough to make a checkpoint only in read syscall entry points? and handle MAP_SHARED by copy up (or rocopyup) on mmap. > "Unfortunately" I'll be taking next week off, so... > That is most fortunate :-) Anyway, I sorted out the dumb rocopy race and cleaning up the code from my tendency to over-code-reuse-with-if-else, so will send a nicer looking version of rocopyup next week. Amir. -- 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
