Re: [rfc git patch] union directory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux