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