This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Union mount readdir support in glibc
- From: Ulrich Drepper <drepper at redhat dot com>
- To: bharata at linux dot vnet dot ibm dot com
- Cc: libc-alpha at sourceware dot org, Jan Blunck <jblunck at suse dot de>, 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>, Mingming Cao <cmm at us dot ibm dot com>, Dave Hansen <haveblue at us dot ibm dot com>
- Date: Thu, 13 Mar 2008 20:53:48 -0700
- Subject: Re: [RFC] Union mount readdir support in glibc
- References: <20080311055527.GA7256@in.ibm.com>
-----BEGIN PGP SIGNED MESSAGE-----
Bharata B Rao wrote:
> readdir in glibc
> glibc readdir would maintain a cache of dirents returned by readdir/getdents
> system call to perform duplicate elimination and whiteout supression.
As an optimization I have no problem with adding the code to glibc if it
does not impact non-union directories. But requiring lockstep update of
kernel and glibc to use a feature like this which is not under control
of the application is a huge problem. I don't think we ever had to
resort to this. I consider this absolutely only the last resort.
Current readdir requires:
fstat (this can probably even be removed)
malloc small buffer
readdir: if buffer is empty
getdents call (read multiple entries)
return next entry
There is very little overhead. Since we copy using getdents multiple
records it is more efficient than implementing readdir in the kernel.
This is how efficient normal directory operations must remain. The only
slight inefficiency is that we have to copy the entries after getdents()
because the d_type field is not in the place we expect it at userlevel.
For this a new interface could help.
To handle union FS at userlevel somewhere in that code sequence (perhaps
in the fstat call) we'd have to recognize such mounts. Before any
agreement on userlevel sorting can be made you'll have to answer a
question Roland already asked:
- - How does this work with NFS?
Regarding questions you have: if a directory currently is read and file
are added or removed, all bets are off.
re seeking: you have to support seeking. There is no way around it.
Once again, if any file has been added/removed, all bets are off. So,
why not provide a cookie similar to what is done today? I think it is
not acceptable to require caching the entire directory content at
userlevel. It's bad enough if we have to store the file names for
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----