Re: io assumptions

tor 2002-12-05 klockan 09.49 skrev Robert Collins:

> That limitation is easy. I'm talking about the following cycle:
>
> storeOpen()->SIO.open()->OS.Open()->SIO.Completed()->storeClosed(error);
>
> So it is a callback based OS behaviour, but occuring immediately.

I still do not get what you are talking about. Who is making the
callback where, on what criterias and when?

Is it the OS that makes the callback as a result of a async OS.Open()
beeing able to complete immediately, or is it something else?

> Well, once we have clear semantics, this can definately be done. The
> semantics are not clear to me on first principles, and while I can study
> the current behaviour, at the moment I think it's somewhat arbitrary and
> inconsistent.

I do not agree.

It is inconsistent if you think there is a direct connection between a
"OS File" and a SIO. There is not.

The SIO is a handle into the fs driver only, and implements a limited
set of functions.

Open/Create returns a SIO handle if possible. This handle does not need
to be connected to a "OS File" for operations to be possible on the SIO.

If the storeio driver implements storage via "OS Files" then the errors
in connecting a SIO to a "OS File" is simply a I/O error.

The storio driver also has the opportunity to refuse the operation
entirely, in which case NULL is returned.

As UFS is syncronous it can signal open/create I/O errors by refusing
the operation (returning NULL). I have no opinion if this is good or bad
and have no problem if this is changed to signal the error via the
callback.

But I still believe that it is a good thing that the storeio driver can
refuse the operation early on without having to first create and return
a SIO handle.

> What design corner? I'm not trying to be difficult here, I just am not
> clear on the issue.

What I am objecting is not the change to signal errors always via the
callback, but the change to not return a SIO until the open/create
operation has completed.

> Ok. This is fine, and fits with my 'speculative reads or writes'
> assumption above. I think we need to be more clear about data loss

If the callback signals error then the object has to be assumed
non-existing and all data lost.

If the callback signals OK then the object may be assumed to be stored
on disk.

There is always a callback unless the caller disappears invalidating the
callback. If the caller disappears before the callback can be made the
status is undefined.

> What about this (thinking out loud):
> storeClose() just signals that the core doesn't want the object anymore.
> if we reference count the object instead, it will detect when it's not
> wanted, and it can just quietly vanish. It's up to the store layers io
> object to clean up properly.

storeClose() may well be implemented by reference counts if you like but
I like to see a "commit" operation in case of swapouts to signal that
all of the object has been stored.

* If the object is opened for writing then storeClose() signals 'I have
written what I need to write. Please tell me when/if it has been
committed to disk'.

* If the object is opened for reading then storeClose() signals 'I am
not interested to receive any more information about this object'. There
is a callback to be consistent with the storeClose() case but in theory
this callback has no function from a data integrity perspective.

The difference between the file_callback and close_callback needs to be
explained better in the API docs. Seems to be missing completely.

Regards
Henrik
Received on Thu Dec 05 2002 - 03:10:46 MST