Re: [fuse-devel] Changes in 4.7.

[Al Viro <viro@ZenIV.linux.org.uk>]

On Wed, Jun 01, 2016 at 02:32:46PM +0200, Stef Bon wrote:

> I understand that a directory is simular to a file, and the struct
> file also applies
> to a directory.
> Thanks a lot for your detailed explanation!
> 
> When does a lseek not affect another? Does this depend on how the
> filesystem deals with
> a directory right? How is it stored? When a directory is nothing more
> than a linked list, where
> new entries are appended at the end, seeking through the linked list
> will not get mixed up
> compared to  using another method, like I use skiplists (and only
> that) for directories.

No, it has nothing to do with the way directory is stored, etc.  After
	int fd1 = open("foo", O_DIRECTORY);
	int fd2 = dup(fd1);
	int fd3 = open("foo", O_DIRECTORY);
lseek() on fd1 and fd2 manipulate the same object; that on fd3 is independent.
Current IO position, both for regular files and directories, is a property
of an object created by open(); dup()/dup2()/fork() create aliases for those
objects.  getdents(2) is serialized on per-open() basis; if two descriptors
are aliases ultimately coming from the same open() call, the calls of
getdents() on them will be treated as if they were sequential calls of
getdents() on the same descriptor - each call will read a new chunk of
directory.  If descriptors result from separate open() calls, getdents() on
one of them has no effect on getdents() on another.

It's exactly the same as for regular files - if you have
	int fd1 = open("bar", 0);	// first channel opened
	int fd2 = dup(fd1);		// fd2 refers to the same channel
	int fd3 = open("bar", 0);	// second channel opened
	char c1, c2, c3;
	read(fd1, &c1, 1);	// offset of the first channel goes 0 -> 1
	read(fd2, &c2, 1);	// offset of the first channel goes 1 -> 2
	read(fd3, &c3, 1);	// offset of the second channel goes 0 -> 1
c1 and c3 will contain the first byte of our file and c2 - the second one.
If you continue that with
	lseek(fd2, 0, SEEK_SET);// offset of the first channel goes 2 -> 0
	read(fd1, &c1, 1);
c1 will be the first byte.  If that lseek() had been done to fd3 instead of
fd2, c1 would be the third byte, since the offset in the first channel would've
been unaffected by the operation on the second one.

For regular files, the kernel serializes read()/write()/lseek() done on
descriptors aliasing each other.  Now it does the same for getdents()/lseek()
of directories.

>From the filesystem point of view, you might see two getdents() called
in parallel only if their results should be unaffected by the order of
operations.