On Fri, Apr 7, 2017 at 4:03 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > One more idea: do it out-of-band (e.g. under workdir) but do it as a > plain directory tree shadowing the lower trees that contains the > forward redirect information. It spares us the implementation of the > database, since the filesystem does it for us. Yes, it can get out of > sync with the overlay, but so can any mapping in-band or out-of-band. > I like this. "don't implement a database of files, because filesystem is already a super complex and optimized database of files metadata" is a design concept I feel strongly about. It always bothered me that is_lower_positive() is not cached in a single place. I am not concerned about getting out of sync to to an implementation bug. I am concerned about not being able to program power fail safe code that does not require calling fsync for metadata operations. Because the shadow directory existence is not a problem we can safely create it anytime before upper rename and if we set a redirect_fh on the shadow dir, we can also do that anytime before rename and we are also safe wrt upper rmdir. So forget the linked list construct. Shadow tree on-disk construct is better in all aspects and it is easier to debug. You do realize that this feature is RO_COMPATIBLE because if workdir will have nested dirs overlay in old kernel will be mounted readonly (at least from some kernel version), which makes me like this idea even more :-) Several lower layers complicates things a bit because path A could have different forward redirects to different upper dirs from different lower layers. I can try to do a POC that assumes there are no redirects in the lower layers and then see how we proceed from there. 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
