This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH 0/2] Union Mount: Directory listing in glibc
- From: Jan Blunck <jblunck at suse dot de>
- To: bsn dot 0007 at gmail dot com
- Cc: libc-alpha at sourceware dot org, Erez Zadok <ezk at cs dot sunysb dot edu>,linux-kernel at vger dot kernel dot org, linux-fsdevel at vger dot kernel dot org,viro at zeniv dot linux dot org dot uk, Christoph Hellwig <hch at lst dot de>,Ulrich Drepper <drepper at redhat dot com>, Mingming Cao <cmm at us dot ibm dot com>,Dave Hansen <haveblue at us dot ibm dot com>,Trond Myklebust <trond dot myklebust at fys dot uio dot no>,bharata at linux dot vnet dot ibm dot com, David Woodhouse <dwmw2 at infradead dot org>
- Date: Tue, 29 Apr 2008 18:04:31 +0200
- Subject: Re: [RFC PATCH 0/2] Union Mount: Directory listing in glibc
- References: <20080429133201.GA9938@localhost.localdomain>
On Tue, Apr 29, bsn.0007@gmail.com wrote:
> The RFC discussed about the information glibc readdir needs to get about
> union mounted directories and I have assumed the following information
> to be available from the kernel for this implementation.
>
> - Kernel would return all the dirents (including duplicates and whiteouts)
> starting from the topmost directory of the union.
>
> - Indication that this directory is a union mounted directory
> I have assumed that kernel would return a "." whiteout as the first
> directory entry of the union. This would tell glibc readdir(3) that it is
> working with a union mounted directory and it needs to do duplicate
> elimination and whiteout suppression. It starts building a dirent cache
> for this purpose.
IIRC the intention was to emit a "." whiteout when "changing" from one
directory to the next. That means when the first directory is completely read
the whiteout is emitted. After that glibc knows to start duplicate
removal.
> Ulrich had suggested that we could use the fstat call to recognize union
> mounts. But looking at the stat structure from stat(2), it was not obvious
> as to which field in there could be used for this purpose. Hence for this
> prototype implementation, I decided to go with what Al Viro suggested, which
> is about using a "." whiteout.
>
> - Indication that kernel is done with returning entries from the topmost
> directory.
> I have assumed that kernel would return a "." whiteout at the beginning
> of each directory of the union. So when glibc gets a 2nd "." whiteout, it
> will start performing duplicate elimination.
See above
> - Whiteout indication
> glibc will depend on dirent->d_type to be set to DT_WHT on a whiteout
> file.
Which makes the new filetype very much visible to the userspace but maybe that
is the price we have to pay.
> Compatibility issues
> --------------------
> There are many versions of dirent structure in glibc and I have tried my
> best to take care of compatibility issues. But I have not really tested
> readdir64 or old_readdir64. Also atleast one version of dirent structure
> doesn't have d_type field and my whiteout suppression logic depends on it
> and uses it in the generic __READDIR routine which gets used by various
> version of readdir and I think this would break that readdir version which
> uses dirent structure w/o d_type. I will be taking care of such compatibility
> issues more cleanly/thoroughly in subsequent posts.
We don't support union mounts on older kernels. Newer kernels return
d_type. So I think we don't have a problem.
Regards,
Jan
--
Jan Blunck <jblunck@suse.de>