From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Thu, 1 Nov 2007 09:29:30 +0000 From: "roger peppe" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] QTCTL? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Topicbox-Message-UUID: e2a9e4ea-ead2-11e9-9d60-3106f5b1d025 On 10/31/07, erik quanstrom wrote: > > using qid.version to indicate the status of the underlying device > > rather than of the file data seems to me like an abuse of the system. > > surely a status file would be a better way of indicating media change? > > yet here you argue that using the qid.version to indicate that the medium > underlying sdXX/data has changed is an "abuse". > > to be a bit picky, the qid.version doesn't indicate the status of the device, > it indicates how many times the media have changed. > > it doesn't make sense for a process to blithly continue writing to the > new medium without getting an error. i agree with that, and for read-only devices, using the version on the data file to indicate media change seems fine. but for writable devices, surely the version number should increment once every time the device has been written? for writable devices, if there was a status file giving some information about the media, perhaps the version number on that would be a better place to record media changes. regarding QTDECENT (or whatever it might be called), i recently came up against this. i've implemented most of a filesystem to allow latency lowering - kind of similar to fcp, but allows naive clients to gain the benefits, and does it for streaming files too. it uses a filesystem at both the server and client sides - the client sends several requests at once, and the server gathers them into a coherent order. the problem being that the server needs to make a decision as to what kind of semantics a given file supports - whether it has to preserve record boundaries as it reads, for example, or what to do if the reader does a seek (for a "decent" file, it can just discard the read-ahead data - for others, it should probably yield an error). i don't really want to teach this filesystem about which files are "conventionally" normal - and it would be nice to just run one instance for an entire exported fs (accessed through another name, as brian stuart's example).