Hi all, While researching and investigating the problems of the new architecture I found a problem with a restoring filesystems (we're storing all resources as a file). It means, while we're restart the filesystem service, the newly booted one doesn't know anything about opened sessions, going far anyone from the clients set didn't know about this recovery too. However, namespace carrier will get an event and that's a point. Restoring all the sessions while getting this event is a bad way. I found a better solution to solve this problem: if filesystem is dead, than fspoint will be marked as dead, but still exists while it has a non-zero reference count. Well, when client makes a direct fs operation it will receive EIO - in this case libc will require a new fspoint information from the carrier. When the carrier will receive this type of request it will send a request to the restored filesystem to recreate this type of connection, decrease reference count on a "dead" fspoint and return new information to the client. After those the client will recreate the session and retry direct request to the newly booted filesystem. I've called this "on-demand restore", because if some sessions will be not used the reference count to the "dead" fspoint will be decreased due to the close() or any type of task interruption. More complex stuff as a drivers registered on the deviofs will care about deviofs restarts and will recreate it's node(s) on event. btw, if we will need to restore driver we will do the same, but it will be moved to the deviofs side.
Any comments, suggestions ? Thanks, _______________________________________________ Jarios-dev mailing list [email protected] http://lists.jarios.org/cgi-bin/mailman/listinfo/jarios-dev
