From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <9ea2d2b4ccb6660726645383f5a0905b@caldo.demon.co.uk>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] vac merge semantics
From: Charles Forsyth <forsyth@caldo.demon.co.uk>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="upas-ycixvkryoxizqoslgsaqrmzmff"
Date: Mon, 19 Aug 2002 23:15:25 +0100
Topicbox-Message-UUID: de9caa70-eaca-11e9-9e20-41e7f4b1d025

This is a multi-part message in MIME format.
--upas-ycixvkryoxizqoslgsaqrmzmff
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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.

--upas-ycixvkryoxizqoslgsaqrmzmff
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <9fans-admin@cse.psu.edu>
Received: from punt-2.mail.demon.net by mailstore for forsyth@caldo.demon.co.uk
          id 1029786005:20:12323:140; Mon, 19 Aug 2002 19:40:05 GMT
Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-2.mail.demon.net
           id aa2012673; 19 Aug 2002 19:39 GMT
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id 9891419A0C; Mon, 19 Aug 2002 15:39:10 -0400 (EDT)
Delivered-To: 9fans@cse.psu.edu
Received: from hamnavoe (hamnavoe.gotadsl.co.uk [213.208.117.150])
	by mail.cse.psu.edu (CSE Mail Server) with SMTP id 27D52199EC
	for <9fans@cse.psu.edu>; Mon, 19 Aug 2002 15:38:03 -0400 (EDT)
To: 9fans@cse.psu.edu
From: Richard Miller <miller@hamnavoe.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20020819193803.27D52199EC@mail.cse.psu.edu>
Subject: [9fans] vac merge semantics
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.11
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Mon, 19 Aug 2002 20:37:32 0100

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

--upas-ycixvkryoxizqoslgsaqrmzmff--