From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulrich Drepper Subject: Re: [RFC] Union mount readdir support in glibc Date: Fri, 14 Mar 2008 00:13:00 -0700 Message-ID: <47DA257C.9060409@redhat.com> References: <20080311055527.GA7256@in.ibm.com> <47D9F6CC.6010009@redhat.com> <20080314053925.GA10722@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: bharata@linux.vnet.ibm.com, libc-alpha@sourceware.org, Jan Blunck , Erez Zadok , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Christoph Hellwig , Mingming Cao , Dave Hansen To: Al Viro Return-path: In-Reply-To: <20080314053925.GA10722@ZenIV.linux.org.uk> List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org List-Id: linux-fsdevel.vger.kernel.org -----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-----