Hi Jamie.

On Fri, Jul 25, 2008 at 08:40:34PM +0100, Jamie Lokier (jamie@shareable.org) wrote:
quoted text
> Consider this:
> 
>    1. Client A reads FILE, and registers its interest in FILE.
>          (Contents are not interesting, e.g. 'Hello_sister')
>    2. Client B does "echo Some_message > /mnt/file".
>        - Truncates the file, sending truncate message to server.
>        - "Writing happes during writeback"...?
>    3. Client B sends a message by back-channel to client A (e.g. ssh command).
>    4. Client A reads FILE again.
> 
> Does client A always see 'Some_message' when it reads the file in step 4?
> That's what I'd call coherence.

If 4. happens after writeback of the client B, then it will see the new
content, otherwise it will see empty page. There are no locks (even
implicit like what is expected in POSIX in exactly this case) in
POHMELFS so far.

quoted text
> For that, the first truncate or write operation on client B must wait
> until a synchronous invalidate request goes to the server, then the
> server sends to all interested clients (A) and waits for a reply, then
> reply to B, and only then can B return from the open()/write() system call.
> 
> And when client A reads the file in step 4, it must send a synchronous
> message to the server which must ask B to write the delayed writeback
> data immediately, and until then, the reply to A will be delayed.
> 
> Is that right?

It _can_ be done that way. But I'm still thinking on how the really
scalable locking (this is a locking mechanism, just implicit) should be
implemented. It is possible to send a message on every write_begin,
which will invalidate appropriate message and every _read_ from that
area will require all writers to flush theirs data. It will be kind of
ME(O)SI cache coherency CPU protocol. It is simple task in current
design, but I'm not yet convinced myself that this is a really scalable
approach. So, there are no locks in POHMELFS _yet_.

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html