This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Union mount readdir support in glibc
- From: Ulrich Drepper <drepper at redhat dot com>
- To: Al Viro <viro at ZenIV dot linux dot org dot uk>
- Cc: bharata at linux dot vnet dot ibm dot com, 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, 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: Fri, 14 Mar 2008 00:13:00 -0700
- Subject: Re: [RFC] Union mount readdir support in glibc
- References: <20080311055527.GA7256@in.ibm.com> <47D9F6CC.6010009@redhat.com> <20080314053925.GA10722@ZenIV.linux.org.uk>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Al Viro wrote:
> How about "the first entry returned by getdents(3) after open() is a whiteout
> for e.g. '.'"? No fstat needed, zero impact for normal directories,
> zero impact for any binaries on old kernels (where you wouldn't have
> unions) and zero impact for old binaries on new kernels unless they
> do getdents() on directory that happens to be a union.
Your definition of "zero impact" doesn't quite match mine. This would
require significant changes.
> And no lockstep...
Of course there is lockstep. It is not under the application's control
whether a directory is a union fs or not. Every implementation except a
pure kernel implementation has this problem.
>> - - How does this work with NFS?
>
> It won't, kernel-side or done in userland.
Why wouldn't a kernel-side implementation work?
> Actually, do we really need it other than to 0 and to current position
> (i.e. full rewind and a no-op)?
Ever heard of the little function "telldir"?
- --
â 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
iEYEARECAAYFAkfaJXwACgkQ2ijCOnn/RHSRpQCZAXNktqSs6WRvxIlTlzUd6GC5
PrAAnRecjUcM6ZHoclzXrFFCsBWuIgid
=8pZl
-----END PGP SIGNATURE-----