From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7e65325a0cd907feca744c030f025319@quanstro.net> To: 9fans@cse.psu.edu Subject: Re: device-specific qid.version behaviour (was Re: [9fans] QTCTL?) From: erik quanstrom Date: Mon, 5 Nov 2007 11:40:31 -0500 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: e92e7f7e-ead2-11e9-9d60-3106f5b1d025 > i'm sorry? the server is the one *generating* the qid, surely? > for instance, in the case of cdfs, the version number comes from the > scsi(2) library function, and doesn't have any necessary correspondence with > qid.vers as found in the data file served by cdfs. so strictly speaking, > the server isn't doing any qid checking at all - it's just looking at > its own data structures. /n/sources/plan9/sys/src/9/port/devsd.c:177 > > using a seperate file to detect media change introduces a > > race. with network-attached media this might be a problem. > > there's a race anyway if you're doing the stat in a separate process. > if you're not, then it's the same either way, no? there is no race. the client does a pread/pwrite blithly. devsd returns -1, Echange if the medium has changed since the fd was opened. > > the fact is, you can't deal with a physical disk like /dev/sdE0/data > > in the same way you can deal with a regular fileserver. > > perhaps not. but by putting device-specific information in qid.vers, > you run the risk that you can't treat a file on a regular fileserver > as if it was a physical disk, and i really like being able to do that. i assume that you mean a file on a fs not the fs itself. the qid.vers is *always* device or fs specific. i don't understand what specific case you think is broken. again, it's not expected that the client look at the qid.vers. nothing would break if you used a file on a fs. (as i do all the time.) you just wouldn't get Echange errors. > and i'm afraid i really disagree with the following: > > > seriously, the fewer rigid rules we make for 9p, > > the more adaptable it will be. > > i feel that real adaptability comes from having a few, well-defined > rules, and freedom within those rules. that way you get > good interoperability, but also flexibility, because the rules > aren't really that restrictive. for me, 9p's unwritten rule seems > to be "if you do it, do it right", whether you're talking > about versions, sizes, read/write offsets, or whatever. as you state it, i agree. but you're arguing against a qid.vers usage that dates back to before web browsers. as i understand it you argue that qid.vers should change for each write for any server. many devices just use 0 for qid.vers and never increment it. so you can't use qid.vers on a stream or any fs that just sets qid.vers to 0. so, in general, one can't use qid.vers as you propose. - erik