On Sun, Nov 9, 2014 at 12:42 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Fri, Nov 07, 2014 at 11:09:59AM -0800, Christoph Hellwig wrote: >> The overlayfs merge introduces a new rename flag to create to whiteouts. >> Should be a fairly easy to implement. >> >> Miklos, do you have any good documentation and/or test cases for this? > > So overlayfs uses some weird char dev hack to implement whiteout > inodes in directories? Why do we need a whiteout inode on disk? > what information is actually stored in the whiteout inode that > overlayfs actually needs? Only readdir and lookup care about > whiteouts, and AFAICT nothing of the inode is ever used except > checking the chrdev/whiteoutdev hack via ovl_is_whiteout(dentry). > > Indeed, whatever happened to just storing the whiteout in the dirent > via DT_WHT and using that information on lookup in the lower > filesystem to mark the dentry returned appropriately without needing > to lookup a real inode? The filesystem is free to implement whiteouts a dirent without an actual inode. But we do need at least an inode in the VFS, since the whiteout needs to be presented to userspace when not part of the overlay. The DT_WHT makes the typical mistake of trying to make the implementation nice, while not caring about user interfaces. This is usually a big mistake, user interfaces are much more important than implementation details, and an already existing file type on which all the usual operations work (stat, unlink) is much better in this respect than a completely new object which is unknown and unmanageable for the vast majority of applications. The special chardev was Linus' idea, but I agree with him completely on this point. Introducing DT_WHT on the userspace API would be much more of a hack than reusing existing objects and operations. Thanks, Miklos _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
