Re: [RFC PATCH 0/5] Union Mount: A Directory listing approach with lseek support



On Wed, 2007-12-05 at 20:07 +0530, Bharata B Rao wrote:
In this approach, the cached dirents are given offsets in the form of
linearly increasing indices/cookies (like 0, 1, 2,...). This helps us to
uniformly define offsets across all the directories of the union
irrespective of the type of filesystem involved. Also this is needed to
define a seek behaviour on the union mounted directory. This cache is stored
as part of the struct file of the topmost directory of the union and will
remain as long as the directory is kept open.

That's a little brute force, don't you think? Especially the memory
exhaustion seems to really make this an undesirable approach.

I think the key here is what kind of consistency we're trying to
provide. If a directory is being changed underneath a reader, what
kinds of guarantees do they get about the contents of their directory
read? When do those guarantees start? Are there any at open() time?

Rather than give each _dirent_ an offset, could we give each sub-mount
an offset? Let's say we have three members comprising a union mount
directory. The first has 100 dirents, the second 200, and the third
10,000. When the first readdir is done, we populate the table like
this:

mount_offset[0] = 0;
mount_offset[1] = 100;
mount_offset[2] = 300;

If someone seeks back to 150, then we subtrack the mount[1]'s offset
(100), and realize that we want the 50th dirent from mount[1].

I don't know whether we're bound to this:

http://www.opengroup.org/onlinepubs/007908775/xsh/readdir.html

"If a file is removed from or added to the directory after the
most recent call to opendir() or rewinddir(), whether a
subsequent call to readdir() returns an entry for that file is
unspecified."

But that would seem to tell me that once you populate a table such as
the one I've described and create it at open(dir) time, you don't
actually ever need to update it.

The storage for this is only comparable to the number of mounts that you
have. One issue comes if we manage to overflow our data types with too
many entries in too many submounts. But, I guess we can just truncate
the directory in that case.

-- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: TypeLoad Exception
    ... First, this is union... ... everyfield must start at the same offset... ... I did not understand the concept of fieldoffsets and ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: A range variable consisting of multiple ranges.
    ... Notice that to make test1 refer to the union of two ranges, ... single cell, A1. ... Offset is zero based. ...
    (microsoft.public.excel.programming)
  • determine member offset in unions
    ... the problem i have is how to determine the offset of member's that are ... DWORD dmDisplayOrientation; ... at which offset to put union members? ...
    (microsoft.public.dotnet.languages.vc)
  • Re: About union
    ... EricLi wrote: ... > union { ... > void main ... element would have to be aligned at offset 8. ...
    (comp.lang.c)
  • [PATCH 03/13] GFS: directories
    ... +* is the number of bytes allocated to the dirent. ... The offset of the next ... +* used as an array of 64-bit block pointers pointing to the leaf blocks. ... error code otherwise ...
    (Linux-Kernel)