Re: [9fans] Design of webfs and webcookies

Re: [9fans] Design of webfs and webcookies

[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

Re: [9fans] Design of webfs and webcookies

[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

Re: [9fans] Design of webfs and webcookies

[Enrico Weigelt]

* Russ Cox <rsc@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: weigelt@metux.de
 mobile: +49 174 7066481   icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] Design of webfs and webcookies

[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

Re: [9fans] Design of webfs and webcookies

[Enrico Weigelt]

* erik quanstrom <quanstro@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 ?)


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

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

Re: [9fans] Design of webfs and webcookies

[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

Re: [9fans] Design of webfs and webcookies

[Ethan Grammatikidis]

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

> * erik quanstrom <quanstro@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?

Re: [9fans] Design of webfs and webcookies

[erik quanstrom]

On Mon Jan 25 15:15:42 EST 2010, eekee57@fastmail.fm wrote:
>
> On 13 Jan 2010, at 4:23 pm, Enrico Weigelt wrote:
>
> > * erik quanstrom <quanstro@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?

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

[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