Re: device-specific qid.version behaviour (was Re: [9fans] QTCTL?)

["roger peppe" <rogpeppe@gmail.com>]

On 11/5/07, erik quanstrom <quanstro@quanstro.net> wrote:
> > 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

???
i'm probably being stupid here, but all i see there is devsd dealing
with its own data structures, with no external qids involved at all.
an SDunit doesn't correspond with any file that devsd uses, as far as i can see.

> 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.

that's absolutely fine. if that's all that's going on, why bother reflecting
the medium change in qid.vers of the data file? just leave it at 0 and be done
with it.

> it's not expected that the client look at the qid.vers.

then why is it exported to the client?

> 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.

that's precisely why i was arguing for a documented exception
to the version rule: if the version is 0, treat the file as "always changed".
it's also why i was arguing against implementations like cdfs
that export a "partial" qid.vers that's neither one thing nor another,
useful only to clients that know exactly what kind of file it is
(in which case the information could be provided some other way).

> fileservers can't be forced to maintain all of the stat fields.
> they are free to lie as the wish.

some lies are worse than others!
for instance, i've seen a server that put the
number of (variably sized) records in a file in its size field,
rather than the number of bytes. i'd definitely say that was
worse than giving zero, though strictly speaking they're
both lies...