Re: [9fans] QTCTL?

[erik quanstrom <quanstro@quanstro.net>]

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

i see the symmetry of what you're saying.  what would be the utility
of maintaining the version this way?  the version, as you describe it,
wouldn't survive reboot and, for network-attached storage, wouldn't be
coherent across machines.  i'm not sure that devices are either
read-only or read-write.  that might depend on the underlying
(hot-pluggable) medium.  and the device driver might not care.

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.  how many
times do you want to want to write a random subset of blocks to a
different device?

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.

- erik