[Coco] DriveWire netdisk interface

[Steven Hirsch]

On Thu, 19 Nov 2009, John W. Linville wrote:

> On Thu, Nov 19, 2009 at 02:19:24PM -0500, Aaron Wolfe wrote:
>
>> I wanted to use webdav, but as far as I could tell, webdav doesn't
>> support reading or writing specific portions of a file.  If i'm wrong
>> about that please let me know!
>
> Hmmm, I wasn't aware of that -- FWIW I'm more of a kernel guy...
>
>> To implement a disk image that "just works" with DECB and OS-9,
>> we have to be able to read and write abitrary 256 byte sections of
>> the file.  I wrote my own simple protocol for this because i didnt
>> see any way to do this with http.
>
> Well, I do appreciate that those semantics exist between the CoCo
> and the DW server.  But I don't think those semantics really need to
> exist between the DW server and the backing store.  In fact, those
> semantics would seem to decrease overall performance and increase the
> chance of disk image corruption in the event of a failure.
>
> I guess what I was thinking is that you would use a pull/modify/push
> model, where the pull would occur when the DW server "mounted" the
> image and the push would occur when a dirty image was "unmounted".
> If the webdav server is worth it's salt, that should at least ensure
> that so long as the DW server didn't push a corrupted image then the
> webdav server images should always be correct.

If pull/modify/push is implemented, I'd suggest using optimistic lock 
semantics.  For example:

- Before pulling the remote copy, obtain a CRC, file timestamp or 
(preferably) both.

- Have your way with the local copy.

- Before writing back the local copy, read the remote CRC and timestamp 
again.  If this information does not match what you read earlier, then 
your optimistic lock failed, i.e. someone else modified it in the 
meantime.  You'll then have to decide semantics: do you warn and allow 
overwriting?  Do you create a versioned copy?  Etc, etc.

Just my 0.02.

Steve


--