On Sat, 2008-11-29 at 17:33 +0100, Miklos Szeredi wrote: > On Fri, 28 Nov 2008, Bharata B Rao wrote: > > On Fri, Nov 28, 2008 at 12:01:32PM +0100, Miklos Szeredi wrote: > > > I've been doing some small fixing/cleanup work on the union directory > > > patches by Jan, and just noticed there's a thread about the union > > > mounts on LKML, so I thought publicizing won't hurt. > > > > Interesting that you call it "union directory", do you have plans to go > > the Plan 9's way of union directories ? > > I think yes, although I never tried Plan9 and don't know the details > of the union directory semantics. > > At first we thought of providing completely read-only unioning (no > whiteouts, no object creation/removal). This gets rid of a _lot_ of > complexity. While this removes a lot of complexity it also makes it unusable for what most people are using UnionFS and AUFS for today. If you want people to use and test the code whiteouts and object creation/removal have to be there from the start or you wont see the LiveCD and thin client people trying it. Considering they make up the overwhelming majority of the users of union directories/mounts it seems important to have them on board. > > > > It's still a work in progress, notably the readdir code currently only > > > works on a few specific filesystem types. > > > > readdir was one of the things on which we couldn't reach a consensus > > on how to do it the right way. We were suggested that we move the > > duplicate elimination into user space and an effort towards this was > > also done (Ref: http://lkml.org/lkml/2008/4/29/248) by moving this > > to glibc readdir. But we weren't sure how this could work for NFS and > > were told that it is required to get the NFS side of things > > sorted out first. So that's where readdir effort stands now afaik. > > Do you have any ideas/plans on this front ? > > The plan is to get a simple kernel implementation first which caches > the directory in 'struct file'. > > Long term we'll see. Maybe the userspace implementation is worth > persuing as well for a more "kernel memory friendly" implementation. > > Thanks, > Miklos > -- > 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 -- 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
