On Tue, Apr 29, bsn.0007@gmail.com wrote:

quoted text
> 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.

quoted text
> 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

quoted text
> - 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.

quoted text
> 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>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html