On 15 November 2010 19:29, erik quanstrom <quans...@labs.coraid.com> wrote:
>> if you mount onto one, you'll see the mounted files
>> on the other.
>>
>> gorka was talking about identifying files from their qid.
>> the version number doesn't help in identifying the file -
>> someone could have modified the file 35 times between
>> stats.
>
> what definition of "file" are you using? you've rejected the
> definition that "file" is identified uniquely by path.
i've only rejected that definition based on observation - intro(5)
does state that the qid path should be unique amongst all files
in the hierarchy, but that's a difficult ideal to live up to
when you're multiplexing filesystems.
>> anyway, even if the version number is the same, the contents
>> may be different.
>
> i claim that a fs with this behavior would be broken. intro(5)
> seems to agree with this claim, unless i'm misreading.
you're right - fossil is broken in this respect, as is exportfs
{cd /mnt/term/dev; ls -lq | sort} for a quick demo.
the only correct way that i can see for a multiplexing fs to avoid this breakage
is the keep track of every qid that it sees, allocating a new qid of its
own for each one. no-one does this because it can use unbounded
memory. instead they map qids on open, because relatively
few files are opened.
that's why i was suggesting a "big enough" qid space as another
possibility. an alternative might be to remove qids from the
Dir structure entirely, returning them only on walk and open.
