Re: [9fans] vac merge semantics

Re: [9fans] vac merge semantics

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

it's probably fairly troublesome, because various things, including the
mount table, use qids for identification.  exportfs goes to a little trouble
to make its outgoing qids unique for that reason.

[-- Attachment #2: Type: message/rfc822, Size: 2669 bytes --]

From: Richard Miller <miller@hamnavoe.demon.co.uk>
To: 9fans@cse.psu.edu
Subject: [9fans] vac merge semantics
Date: Mon, 19 Aug 2002 20:37:32 0100
Message-ID: <20020819193803.27D52199EC@mail.cse.psu.edu>

When vac(1) file trees of depth > 1 are merged with 'vac -m', the resulting
tree when served by vacfs(1) can contain (?usually will contain) multiple
files with identical qid values.

Demonstration:

	cpu% mkdir one
	cpu% echo one a >one/a
	cpu% mkdir two
	cpu% echo two b >two/b
	cpu% vac -f one.vac one
	cpu% vac -f two.vac two
	cpu% vac -f both.vac -m one.vac two.vac
	cpu% vacfs -m /n/kremvax both.vac
	cpu% ls -lq /n/kremvax
	(0000000000000003 0 80) d-rwxrwxr-x M 61 miller miller 0 Aug 19 19:56 /n/kremvax/one
	(0000000000000006 0 80) d-rwxrwxr-x M 61 miller miller 0 Aug 19 19:56 /n/kremvax/two
	cpu% ls -lq /n/kremvax/*
	(0000000000000001 0 00) --rw-rw-r-- M 61 miller miller 6 Aug 19 19:56 /n/kremvax/one/a
	(0000000000000001 0 00) --rw-rw-r-- M 61 miller miller 6 Aug 19 19:56 /n/kremvax/two/b
	cpu% grep . /n/kremvax/*/*
	/n/kremvax/one/a:one a
	/n/kremvax/two/b:two b

No, I haven't got a correction for this one.  I'm wondering how much of a Bad Thing
it is.  Clearly it contradicts the specification in intro(5) that qids are unique
within a server hierarchy.  Although I've never been very clear about what qids are
used for in practice, it would seem for example that using cfs(4) to cache a merged
vacfs tree, or mounting it with '-C', would lead to serious confusion.

-- Richard Miller

Re: [9fans] vac merge semantics

[Richard Miller]

> I`ll fix this when I get back fro, vacation...

OK, I'll wait.

The reason I started looking at vac qids is that I would like to
suggest adding an option flag, say '-q', to vacfs to cause it to
report qids in Rstat and Rread(dir) with respect to the original
file server - i.e.  {VacDir.p9path, VacDir.p9version} instead of
VacDir.qid.

Why is this useful?  Without it, if you copy a vac file tree from
one venti server to another using vacfs => vac, the original p9
qids will be lost, so 'vac -q' will not work on the new server.
Also, there may be some historical / forensic value in keeping the
original qids and making them visible via 'vacfs -q'.

The downside is that 'vacfs -q' on a merged vac tree could result
in duplicate qids.  So the man page could say "don't use -q on a
merged vac tree unless you're sure you know what you're doing",
or this could be enforced by having a Merged flag in the vac root
which would cause vacfs to refuse to honour '-q'.

Request for comments?

-- Richard Miller

Re: [9fans] vac merge semantics

[Sean Quinlan]

All the info needed to get the qids right is available,
however vacfs does not yet have the code that uses this info.
I`ll fix this when I get back fro, vacation...

the idea is that each tree that is merged contains the
max qid - vac leaves the correct size hole in the qid`
space and info that vacfs is supposed to use to
offset the qids in the merged tree...

seanq

> The mount table works by using qid's.  Start playing fast and loose and
> you can end up with some very strange name spaces.

Re: [9fans] vac merge semantics

[presotto]

[-- Attachment #1: Type: text/plain, Size: 123 bytes --]

The mount table works by using qid's.  Start playing fast and loose
and you can end up with some very strange name spaces.

[-- Attachment #2: Type: message/rfc822, Size: 4442 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 202 bytes --]

it's probably fairly troublesome, because various things, including the
mount table, use qids for identification.  exportfs goes to a little trouble
to make its outgoing qids unique for that reason.

[-- Attachment #2.1.2: Type: message/rfc822, Size: 2669 bytes --]

From: Richard Miller <miller@hamnavoe.demon.co.uk>
To: 9fans@cse.psu.edu
Subject: [9fans] vac merge semantics
Date: Mon, 19 Aug 2002 20:37:32 0100
Message-ID: <20020819193803.27D52199EC@mail.cse.psu.edu>

When vac(1) file trees of depth > 1 are merged with 'vac -m', the resulting
tree when served by vacfs(1) can contain (?usually will contain) multiple
files with identical qid values.

Demonstration:

	cpu% mkdir one
	cpu% echo one a >one/a
	cpu% mkdir two
	cpu% echo two b >two/b
	cpu% vac -f one.vac one
	cpu% vac -f two.vac two
	cpu% vac -f both.vac -m one.vac two.vac
	cpu% vacfs -m /n/kremvax both.vac
	cpu% ls -lq /n/kremvax
	(0000000000000003 0 80) d-rwxrwxr-x M 61 miller miller 0 Aug 19 19:56 /n/kremvax/one
	(0000000000000006 0 80) d-rwxrwxr-x M 61 miller miller 0 Aug 19 19:56 /n/kremvax/two
	cpu% ls -lq /n/kremvax/*
	(0000000000000001 0 00) --rw-rw-r-- M 61 miller miller 6 Aug 19 19:56 /n/kremvax/one/a
	(0000000000000001 0 00) --rw-rw-r-- M 61 miller miller 6 Aug 19 19:56 /n/kremvax/two/b
	cpu% grep . /n/kremvax/*/*
	/n/kremvax/one/a:one a
	/n/kremvax/two/b:two b

No, I haven't got a correction for this one.  I'm wondering how much of a Bad Thing
it is.  Clearly it contradicts the specification in intro(5) that qids are unique
within a server hierarchy.  Although I've never been very clear about what qids are
used for in practice, it would seem for example that using cfs(4) to cache a merged
vacfs tree, or mounting it with '-C', would lead to serious confusion.

-- Richard Miller

[9fans] vac merge semantics

[Richard Miller]

When vac(1) file trees of depth > 1 are merged with 'vac -m', the resulting
tree when served by vacfs(1) can contain (?usually will contain) multiple
files with identical qid values.

Demonstration:

	cpu% mkdir one
	cpu% echo one a >one/a
	cpu% mkdir two
	cpu% echo two b >two/b
	cpu% vac -f one.vac one
	cpu% vac -f two.vac two
	cpu% vac -f both.vac -m one.vac two.vac
	cpu% vacfs -m /n/kremvax both.vac
	cpu% ls -lq /n/kremvax
	(0000000000000003 0 80) d-rwxrwxr-x M 61 miller miller 0 Aug 19 19:56 /n/kremvax/one
	(0000000000000006 0 80) d-rwxrwxr-x M 61 miller miller 0 Aug 19 19:56 /n/kremvax/two
	cpu% ls -lq /n/kremvax/*
	(0000000000000001 0 00) --rw-rw-r-- M 61 miller miller 6 Aug 19 19:56 /n/kremvax/one/a
	(0000000000000001 0 00) --rw-rw-r-- M 61 miller miller 6 Aug 19 19:56 /n/kremvax/two/b
	cpu% grep . /n/kremvax/*/*
	/n/kremvax/one/a:one a
	/n/kremvax/two/b:two b

No, I haven't got a correction for this one.  I'm wondering how much of a Bad Thing
it is.  Clearly it contradicts the specification in intro(5) that qids are unique
within a server hierarchy.  Although I've never been very clear about what qids are
used for in practice, it would seem for example that using cfs(4) to cache a merged
vacfs tree, or mounting it with '-C', would lead to serious confusion.

-- Richard Miller