From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] QTCTL? From: erik quanstrom Date: Thu, 1 Nov 2007 08:11:53 -0400 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: e2b9d544-ead2-11e9-9d60-3106f5b1d025 >> 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