On Tue, Mar 11, 2008 at 01:09:29AM -0700, Roland McGrath wrote: > It seems very unlikely you'd come up with a version of this plan that we'd > find acceptable in glibc. readdir does buffering, sometimes entry format > conversion, and it can skip dummy entries. That's it. It's not going to > become a big hairy thing with all kinds of new state. Sorry. In the approach we are suggesting, at the minimum, glibc readdir would have to maintain a unified cache of dirents with the knowlege of whiteouts (DT_WHT). Would that be too much ? > > This really is the kernel filesystem's problem. It just doesn't make sense > to expect userland to implement half of your directory semantics for you. > What are you going to do when you want to export a union directory to NFS? > readdir is a filesystem operation. You're implementing a filesystem. Not really. In Union Mount, most of the unification support is done at VFS layer with some support from filesystems (for things like whiteouts). It is Unionfs which implements a new filesystem to achieve unification. Unification is not purely a kernel filesystem's problem, it involves both VFS and FS. > > Exposing DT_WHT entries may be useful as a user feature. (BSD had unions > with whiteouts years ago, and their ls et al have options to let you see > and operate on whiteouts explicitly so users can make sense of strange > situations with unions.) But even for that, we'd have to consider the > compatibility issues. AFAIK, even BSD implements duplicate elimination and whiteout suppression in the userland. Thanks for your comments. Regards, Bharata. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
