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

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

[roger peppe]

On 11/1/07, erik quanstrom <quanstro@quanstro.net> wrote:
> i think it makes sense to use the medium changes (not connections, if
> possible) to determine the version.  the marvell and aoe driver
> consider a device changed if the serial# or number of sectors
> change.that is something most io clients are interested in.

this kind of thing is fine until you want to run software that
uses the original notion of "version". for instance, i suppose it's
not inconceivable that you could run something like cfs over
such a device.

turning things around, by providing device-specific versioning behavior,
you can end up with clients that won't work well when run over normal
files. if a client expects the version number to change only when the
media changes, then it's quite likely to be fairly surprised if
the version number changes every time it writes some data.

that's why i think that preserving standard semantics is a Good Thing.
it preserves filesystem transparency, one of the nicest
things about plan 9.

> it does not seem too much of a stretch.  the stat.size field isn't the
> "file size" of a stream (whatever that means).  so i think this is
> well within the tradition.

in what filesystems does stat.size hold anything other than zero
(don't know) or the
number of bytes that are currently readable from the file?

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

[erik quanstrom]

> On 11/1/07, erik quanstrom <quanstro@quanstro.net> wrote:
>> i think it makes sense to use the medium changes (not connections, if
>> possible) to determine the version.  the marvell and aoe driver
>> consider a device changed if the serial# or number of sectors
>> change.that is something most io clients are interested in.
> 
> this kind of thing is fine until you want to run software that
> uses the original notion of "version". for instance, i suppose it's
> not inconceivable that you could run something like cfs over
> such a device.
> 
> turning things around, by providing device-specific versioning behavior,
> you can end up with clients that won't work well when run over normal
> files. if a client expects the version number to change only when the
> media changes, then it's quite likely to be fairly surprised if
> the version number changes every time it writes some data.

i still don't agree that this is anomolous behavior.  when the medium
has changed, the file has changed.  it has a new set, and possibly a different
number of blocks.  this is exactly the case where ken's fs or fossil
assign a new qid.vers.

further, this behavior only holds for /dev/sdXX/data and a few other files, like
/dev/fd?^(diskc ctl).  i don't see how this could break anything.
could you give a senario that would be broken in this case?
i can't find any programs that use the qid.version for anything except
to infer that a file has changed if it qid.vers has changed.  

by the way, your claim that this is new behavior is not correct.
russ' plan9history shows that the floppy driver use the qid.vers in
this way on 1991/0925.  
	http://swtch.com/cgi-bin/plan9history.cgi?f=pc/devfloppy.c;v=history

- erik

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

[roger peppe]

On 11/5/07, erik quanstrom <quanstro@quanstro.net> wrote:
> i still don't agree that this is anomolous behavior.  when the medium
> has changed, the file has changed.  it has a new set, and possibly a different
> number of blocks.  this is exactly the case where ken's fs or fossil
> assign a new qid.vers.

i agree it's perfectly reasonable to assign a new qid.vers in this case.
but if it's going to do this, i think it should also assign a new qid.vers
when the data file has been written to.

> further, this behavior only holds for /dev/sdXX/data and a few other files, like
> /dev/fd?^(diskc ctl).  i don't see how this could break anything.
> could you give a senario that would be broken in this case?
> i can't find any programs that use the qid.version for anything except
> to infer that a file has changed if it qid.vers has changed.

i gave one scenario. to expand on it: say dossrv expected this behaviour.
it would then do an occasional stat; if the qid.vers had changed, it
would assume that the floppy had been swapped and abort with an error.
this would mean that i could no longer use dossrv on a conventional
file, because every time dossrv wrote to the file, it would then
abort, thinking that the floppy had been swapped because the version
number had changed.

as it happens, neither dossrv, nor 9660srv do check the version
number this way, as far as i can see (even though 9660srv could, without loss
of generality)

> by the way, your claim that this is new behavior is not correct.
> russ' plan9history shows that the floppy driver use the qid.vers in
> this way on 1991/0925.
>         http://swtch.com/cgi-bin/plan9history.cgi?f=pc/devfloppy.c;v=history

um, i don't think i said that it was new behaviour. i did say that i thought it
was an abuse of the semantics, and i still think so. to me the devfloppy
code you point to looks like it was just using the Chan as a
convenient place to store
the version, rather than to deliberately make the information
available publicly.
i'm probably wrong about that, but i don't think it makes a good precedent.
i still think that having a separate file representing the medium itself,
rather than the data contained within it, would be a better solution.

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

[erik quanstrom]

>> further, this behavior only holds for /dev/sdXX/data and a few other files, like
>> /dev/fd?^(diskc ctl).  i don't see how this could break anything.
>> could you give a senario that would be broken in this case?
>> i can't find any programs that use the qid.version for anything except
>> to infer that a file has changed if it qid.vers has changed.
> 
> i gave one scenario. to expand on it: say dossrv expected this behaviour.
> it would then do an occasional stat; if the qid.vers had changed, it
> would assume that the floppy had been swapped and abort with an error.
> this would mean that i could no longer use dossrv on a conventional
> file, because every time dossrv wrote to the file, it would then
> abort, thinking that the floppy had been swapped because the version
> number had changed.

i think something's lost in the translation here.

the client is not responsible for checking the qid.version.  the
server (e.g. devsd, devaoe or devfloppy) does the qid checking
itself.  the server checks if the chan.qid.vers != data.vers then
issue Echange.

i don't see the utilitiy in incrementing the vers on write.

using a seperate file to detect media change introduces a
race.  with network-attached media this might be a problem.

- erik

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

[erik quanstrom]

> um, i don't think i said that it was new behaviour. i did say that i thought it
> was an abuse of the semantics, and i still think so. to me the devfloppy
> code you point to looks like it was just using the Chan as a
> convenient place to store

i think you should complain to presoto or rob.  it would be helpful to
do so in 1990.  you may need a time machine.

while you're at it, tell ken to spell "creat" with an "e".

and you need to complain about the abuse of wstat() to imply device
i/o flushing.

☺ (just to remove any doubt)

seriously, the fewer rigid rules we make for 9p,
the more adaptable it will be.

the history migration process i built for kenfs
(/n/sources/contrib/quanstro/history.ms)
insures that for any two files on the original fs,

	a.file1.qid.vers == a.file2.qid.vers =>
		b.file1.qid.vers == b.file2.qid.vers.

russ thinks this is too strong an assumption in general.
i was just targeting fileservers like kenfs or fossil.
but in general, russ is correct.  this wouldn't work
for devsd data files, for the reasons you mention.

> turning things around, by providing device-specific versioning behavior,
> you can end up with clients that won't work well when run over normal
> files. if a client expects the version number to change only when the
> media changes, then it's quite likely to be fairly surprised if
> the version number changes every time it writes some data.

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.  clients
that make strong assumptions about ownership, dates or
qid.vers are going to get burned by devices serving up physical
media.

try doing ls -lt /mail/fs/mbox.

- erik

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

[roger peppe]

On 11/5/07, erik quanstrom <quanstro@quanstro.net> wrote:
> i think something's lost in the translation here.
>
> the client is not responsible for checking the qid.version.  the
> server (e.g. devsd, devaoe or devfloppy) does the qid checking
> itself.

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.

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

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

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.

> try doing ls -lt /mail/fs/mbox.

i wish this worked!

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

[erik quanstrom]

> 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

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

[erik quanstrom]

>> try doing ls -lt /mail/fs/mbox.
> 
> i wish this worked!

i do, too.  (i made it work in my version.)  but that's really beside the point.
fileservers can't be forced to maintain all of the stat fields.
they are free to lie as the wish.

- erik

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

[roger peppe]

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

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

[Skip Tavakkolian]

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

it's supposed to change every time the file is modified.

i would think any mods would include the case where multiple
reads from the same file (e.g. ctl) at the same offset returns
new results.  but this would be excessive.

maybe 9p2010 Tread/Twrite could include the qid, which may be
supplied by the client (or left out).  if qid is supplied then the fs
has the option to enforce it; otherwise it works as it does now.

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

[erik quanstrom]

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

the qid.vers does get exported.  i don't think there's a copy of the version stashed
in the kernel that is not visable from the outside.

	; cd /dev/sdD0	# cdrom
	; ls -q
	(0000000004400004 0 00) ctl
	(0000000004400005 0 00) raw
(inserts a cd)
	; ls -q
	(0000000004400004 1 00) ctl
	(0000000004400006 1 00) data
	(0000000004400005 1 00) raw
(reinserts the same cd)
	; ls -q
	(0000000004400004 2 00) ctl
	(0000000004400006 2 00) data
	(0000000004400005 2 00) raw

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

there's another way to look at this situation.  the fileservers do not
lie.  they are always accurate.  the client's assumptions are faulty.
;-)

this issue deserves some more thought.  stat(5) says length is in bytes.
is stat(5) wrong?  

if we allow too much freedom in 9p, then we will not be able to
write general tools.  if we don't allow enough, we will not be able to
write tools easily and succinctly.

i think this particular case is not too much of a problem because qid.vers
is not used by very many tools, and most of them assume a fileserver
like kenfs or fossil.  (if you can point to a program that devsd breaks,
i'd be interested.)

- erik

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

[Eric Van Hensbergen]

On 11/5/07, Skip Tavakkolian <9nut@9netics.com> wrote:
>
> maybe 9p2010 Tread/Twrite could include the qid, which may be
> supplied by the client (or left out).  if qid is supplied then the fs
> has the option to enforce it; otherwise it works as it does now.
>

Confused as to what you are saying here - could you clarify?

         -eric

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

[Skip Tavakkolian]

>> maybe 9p2010 Tread/Twrite could include the qid, which may be
>> supplied by the client (or left out).  if qid is supplied then the fs
>> has the option to enforce it; otherwise it works as it does now.
>>
> 
> Confused as to what you are saying here - could you clarify?

when client opens a file and gets a qid back, it assumes that the
fid it uses corresponds to the qid it was given. if in subsequent reads
the file changes but reads for that fid still succeed (even though
file contents have changed and the old qid doesn't match the "current"
file), this could be a problem. this is the case with ctl files. read the
same file at the same offset, get different answers each time but
the qid.vers stays the same.

for a client that cares (e.g.  something that caches the data), it
could ask on every read which version of the file it really wants.  if
it doesn't care which version, it would leave it up to the fs to
decide whether it will strictly enforce version change.  might
answer questions like what should the output of cat after sleep
really be?

cpu% ramfs
cpu% cd /tmp
cpu% ls
cpu% touch foo
cpu% cat foo
cpu% {sleep 20 && cat}<foo&
cpu% echo 123 > foo
cpu% 123


now in slow motion. which qid should fid 976 correspond to?

cpu% ramfs -D
ramfs 137391:<-Tversion tag 65535 msize 8216 version '9P2000'
ramfs 137391:->Rversion tag 65535 msize 8216 version '9P2000'
ramfs 137391:<-Tattach tag 9 fid 1122 afid -1 uname fst aname 
ramfs 137391:->Rattach tag 9 qid (0000000000000000 0 d)
cpu% cd /tmp
cpu% touch foo
ramfs 137391:<-Twalk tag 9 fid 1122 newfid 1238 nwname 1 0:touch 
ramfs 137391:->Rerror tag 9 ename file does not exist
ramfs 137391:<-Twalk tag 9 fid 1122 newfid 976 nwname 1 0:foo 
ramfs 137391:->Rerror tag 9 ename file does not exist
ramfs 137391:<-Twalk tag 9 fid 1122 newfid 1033 nwname 1 0:foo 
ramfs 137391:->Rerror tag 9 ename file does not exist
ramfs 137391:<-Twalk tag 9 fid 1122 newfid 1033 nwname 0 
ramfs 137391:->Rwalk tag 9 nwqid 0 
ramfs 137391:<-Tcreate tag 9 fid 1033 name foo perm %M% mode 438
ramfs 137391:->Rcreate tag 9 qid (0000000000000001 0 ) iounit 8192 
ramfs 137391:<-Twstat tag 9 fid 1033 stat '' '' '' '' q (ffffffffffffffff 4294967295 dalA) m 037777777777 at -1 mt 1194291310 l -1 t 65535 d -1
ramfs 137391:->Rwstat tag 9
ramfs 137391:<-Tclunk tag 9 fid 1033
ramfs 137391:->Rclunk tag 9
cpu% {sleep 30 && cat}<foo&
cpu% ramfs 137391:<-Twalk tag 9 fid 1122 newfid 976 nwname 1 0:foo 
ramfs 137391:->Rwalk tag 9 nwqid 1 0:(0000000000000001 0 ) 
ramfs 137391:<-Topen tag 9 fid 976 mode 0
ramfs 137391:->Ropen tag 9 qid (0000000000000001 0 ) iounit 8192 
ramfs 137391:<-Twalk tag 9 fid 1122 newfid 1188 nwname 1 0:sleep 
ramfs 137391:->Rerror tag 9 ename file does not exist

cpu% echo 123 > foo
ramfs 137391:<-Twalk tag 46 fid 1122 newfid 1247 nwname 1 0:foo 
ramfs 137391:->Rwalk tag 46 nwqid 1 0:(0000000000000001 0 ) 
ramfs 137391:<-Topen tag 46 fid 1247 mode 17
ramfs 137391:->Ropen tag 46 qid (0000000000000001 1 ) iounit 8192 
ramfs 137391:<-Twalk tag 46 fid 1122 newfid 1033 nwname 1 0:echo 
ramfs 137391:->Rerror tag 46 ename file does not exist
ramfs 137391:<-Twrite tag 46 fid 1247 offset 0 count 4 '123
'
ramfs 137391:->Rwrite tag 46 count 4
ramfs 137391:<-Tclunk tag 46 fid 1247
ramfs 137391:->Rclunk tag 46
cpu% ls -q foo
ramfs 137391:<-Twalk tag 46 fid 1122 newfid 1188 nwname 1 0:ls 
ramfs 137391:->Rerror tag 46 ename file does not exist
ramfs 137391:<-Twalk tag 46 fid 1122 newfid 1247 nwname 1 0:foo 
ramfs 137391:->Rwalk tag 46 nwqid 1 0:(0000000000000001 2 ) 
ramfs 137391:<-Tstat tag 46 fid 1247
ramfs 137391:->Rstat tag 46  stat 'foo' 'fst' 'fst' 'fst' q (0000000000000001 2 ) m 0664 at 1194291310 mt 1194291342 l 4 t 65535 d -256
ramfs 137391:<-Tclunk tag 46 fid 1247
ramfs 137391:->Rclunk tag 46
(0000000000000001 2 00) foo
cpu% ramfs 137391:<-Twalk tag 9 fid 1122 newfid 1247 nwname 1 0:cat 
ramfs 137391:->Rerror tag 9 ename file does not exist
ramfs 137391:<-Tread tag 9 fid 976 offset 0 count 8192
ramfs 137391:->Rread tag 9 count 4 '123
'
123
ramfs 137391:<-Tread tag 9 fid 976 offset 4 count 8192
ramfs 137391:->Rread tag 9 count 0 ''
ramfs 137391:<-Tclunk tag 9 fid 976
ramfs 137391:->Rclunk tag 9

cpu% 

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

[Skip Tavakkolian]

>>> maybe 9p2010 Tread/Twrite could include the qid, which may be
>>> supplied by the client (or left out).  if qid is supplied then the fs
>>> has the option to enforce it; otherwise it works as it does now.

simpler yet, a flag to open that would tell the fs it should strictly
enforce the change notice by returning an error for a subsequent
read if the file was changed after the open.

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

[roger peppe]

On 11/5/07, erik quanstrom <quanstro@quanstro.net> wrote:
> the qid.vers does get exported.

indeed it does. but if clients aren't expected to make use of it,
why *is* it exported? i guess i'm arguing that the notions of device
medium version (a.k.a. nchanges) and file version are two
separate things, and it doesn't really make sense to present
the former as the latter.

> there's another way to look at this situation.  the fileservers do not
> lie.  they are always accurate.  the client's assumptions are faulty.
> ;-)

no, no, that's so wrong! a fileserver is lying when it presents
metadata that isn't interpretable by reading the rules set out
in section 5 of the manual. the rules are sometimes
bendable, as you point out, depending on who relies on them, but i think it's
a good principle to try to stand behind.

> this issue deserves some more thought.  stat(5) says length is in bytes.
> is stat(5) wrong?

no, stat(5) is axiomatically right...

> if we allow too much freedom in 9p, then we will not be able to
> write general tools.  if we don't allow enough, we will not be able to
> write tools easily and succinctly.

i'm not sure how much bending the rules facilitates easy and succinct tool
writing. it's always tempting, but rarely worth it, i reckon, and this
particular case
definitely doesn't show that IMHO.

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

[erik quanstrom]

>> the qid.vers does get exported.
> 
> indeed it does. but if clients aren't expected to make use of it,
> why *is* it exported? i guess i'm arguing that the notions of device
> medium version (a.k.a. nchanges) and file version are two
> separate things, and it doesn't really make sense to present
> the former as the latter.

why supress it?  it might be useful to some applications to notice
media change and act without needing to do i/o.

>> there's another way to look at this situation.  the fileservers do not
>> lie.  they are always accurate.  the client's assumptions are faulty.
>> ;-)
> 
> no, no, that's so wrong! a fileserver is lying when it presents
> metadata that isn't interpretable by reading the rules set out
> in section 5 of the manual. the rules are sometimes
> bendable, as you point out, depending on who relies on them, but i think it's
> a good principle to try to stand behind.
> 
>> this issue deserves some more thought.  stat(5) says length is in bytes.
>> is stat(5) wrong?
> 
> no, stat(5) is axiomatically right...

who made that rule?  if you believe that, you might want to submit a
number of patches against the plan 9 kernel since it's clearly wrong.

>> if we allow too much freedom in 9p, then we will not be able to
>> write general tools.  if we don't allow enough, we will not be able to
>> write tools easily and succinctly.
> 
> i'm not sure how much bending the rules facilitates easy and succinct tool
> writing. it's always tempting, but rarely worth it, i reckon, and this
> particular case
> definitely doesn't show that IMHO.

really?  so you're writing to a cd and you forget about it.  you're
between sessions when you swap cds.  /dev/sdXX should
a)  allow you to continue writing, wrecking the second cd, or
b)  give you an error.
or, you've read a directory on a floppy.  somebody swaps the flop.
you want
a)  to get the old information
b)  for dosfs to get wacked over the head so it rereads everything.

if you choose b), you need devsd to act like it does.

- erik

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

[Charles Forsyth]

> really?  so you're writing to a cd and you forget about it.  you're
> between sessions when you swap cds.  /dev/sdXX should
> a)  allow you to continue writing, wrecking the second cd, or
> b)  give you an error.
> or, you've read a directory on a floppy.  somebody swaps the flop.
> you want
> a)  to get the old information
> b)  for dosfs to get wacked over the head so it rereads everything.
> 
> if you choose b), you need devsd to act like it does.

i don't understand why qid.vers is involved.
it's the read and writes that mustn't be misleading, so they
return a suitable diagnostic (the one that's used by devsd.c is reasonably clear-cut,
but devfloppy.c's could be better).  that condition lasts until the device
is reopened (or whatever is appropriate).  it works for exported devices.
i've probably just lost the plot, which i think is easy enough,
both for me anyway, and probably for anyone in this case.