[9fans] Design of webfs and webcookies

[Dimitry Golubovsky]

Hi,

Actually I stumbled upon the DMEXCL support trying to use webfs and
webcookies in order to run abaco.

As I see from webcookies source code, all cookies are stored in one
file, that's why exclusive access is necessary.

Will anything get worse if each cookie is stored in its own file* ?
And then webfs and websookies server would just mirror that at the
mount point (or even no server at all would be needed)?

Thanks.

--------------------------
* except for storage fragmentation, but IMHO with modern Linux FS this
is not a huge issue, would Plan9 native FS still suffer?

--
Dimitry Golubovsky

Anywhere on the Web

[erik quanstrom]

> Will anything get worse if each cookie is stored in its own file* ?

if a site has more than 1 cookie managed as a pair, you could
get them out-of-sync by not locking.

what's really wanted here is an atomic create/write/close so that
one process (we don't care which one) is responsible for the whole
file. i think you could get this behavior by creating a temporary
keyfile and then an rename (wstat), which is atomic.

- erik

[Russ Cox]

> what's really wanted here is an atomic create/write/close so that
> one process (we don't care which one) is responsible for the whole
> file. i think you could get this behavior by creating a temporary
> keyfile and then an rename (wstat), which is atomic.

what's really wanted here (and i wrote the code)
is an atomic open/read/write/close, so that different
processes can update the file in sequence without
stepping on or losing each others changes.
DMEXCL provides that; create+(remove+)wstat does not.

russ

[Enrico Weigelt]

* Russ Cox <r...@swtch.com> wrote:
> > what's really wanted here is an atomic create/write/close so that
> > one process (we don't care which one) is responsible for the whole
> > file. i think you could get this behavior by creating a temporary
> > keyfile and then an rename (wstat), which is atomic.
>

> what's really wanted here (and i wrote the code)
> is an atomic open/read/write/close, so that different
> processes can update the file in sequence without
> stepping on or losing each others changes.
> DMEXCL provides that; create+(remove+)wstat does not.

Just curious: can an 9P server cleanly differenciate between clients ?
This would be a great help for transaction isolation, IMHO.

w/o having looked at cookiefs yet, but I would do it like that:

* get cookies by reading /site-cookies/<site>
* set cookies by writing "<site>: foo=bar" to /set pipe
(which can stay open for as long as you want)

This should minimize the amount of messages/roundtrips required in
normal operation and make the client-side really trivial. An non-
blocking write to the "set" file should also reduce latency
(especially when having remote profiles)

cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: wei...@metux.de
mobile: +49 174 7066481 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

[erik quanstrom]

> Just curious: can an 9P server cleanly differenciate between clients ?
> This would be a great help for transaction isolation, IMHO.
>
> w/o having looked at cookiefs yet, but I would do it like that:
>
> * get cookies by reading /site-cookies/<site>
> * set cookies by writing "<site>: foo=bar" to /set pipe
> (which can stay open for as long as you want)
>
> This should minimize the amount of messages/roundtrips required in
> normal operation and make the client-side really trivial. An non-
> blocking write to the "set" file should also reduce latency
> (especially when having remote profiles)

i think you misunderstand the problem. cookiefs' fs interface
is not the issue. cookiefs' robustness when storing the cookies
on the fileserver in the face of multiple concurrently running
cookiefs' is.

- erik

[Enrico Weigelt]

* erik quanstrom <quan...@quanstro.net> wrote:

> i think you misunderstand the problem. cookiefs' fs interface
> is not the issue. cookiefs' robustness when storing the cookies
> on the fileserver in the face of multiple concurrently running
> cookiefs' is.

ah, you're talking about the situation when multiple cookiefs
instances running on the same storage ? hmm, that's the classical
multi-access problem ;-O

but how do you get into that situation in the first place ?
(more to the point: who starts these multiple instances ?)

[Russ Cox]

> but how do you get into that situation in the first place ?
> (more to the point: who starts these multiple instances ?)

cookiefs (or upas/fs, etc.) running on multiple terminals
connected to the same shared file server. or in multiple windows.

russ

[Ethan Grammatikidis]

On 13 Jan 2010, at 4:23 pm, Enrico Weigelt wrote:

> * erik quanstrom <quan...@quanstro.net> wrote:
>
>> i think you misunderstand the problem. cookiefs' fs interface
>> is not the issue. cookiefs' robustness when storing the cookies
>> on the fileserver in the face of multiple concurrently running
>> cookiefs' is.
>
> ah, you're talking about the situation when multiple cookiefs
> instances running on the same storage ? hmm, that's the classical
> multi-access problem ;-O
>
> but how do you get into that situation in the first place ?
> (more to the point: who starts these multiple instances ?)

Wouldn't multiple instances of cookiefs neatly provide transaction
isolation?

[erik quanstrom]

i don't see how you could get acid semantics without locking
the cookie file for the duration of each http exchange. this is because
one can't predict the returned cookies or abort the request and try
again. sending the same http request twice might end up charging
your credit card twice.

i'm not sure this level of inconsistency matters.

- erik