From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Jamie Lokier <jamie@shareable.org>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [0/3] POHMELFS high performance network filesystem. IPv6 support, documentation update.
Date: Sat, 26 Jul 2008 00:35:13 +0400 [thread overview]
Message-ID: <20080725203512.GA10873@2ka.mipt.ru> (raw)
In-Reply-To: <20080725194033.GA16133@shareable.org>
Hi Jamie.
On Fri, Jul 25, 2008 at 08:40:34PM +0100, Jamie Lokier (jamie@shareable.org) wrote:
> 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.
> 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
prev parent reply other threads:[~2008-07-25 20:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-25 19:01 [0/3] POHMELFS high performance network filesystem. IPv6 support, documentation update Evgeniy Polyakov
2008-07-25 19:02 ` [1/3] POHMELFS high performance network filesystem. Documentation Evgeniy Polyakov
2008-07-25 19:03 ` [2/3] POHMELFS high performance network filesystem. VFS changes Evgeniy Polyakov
2008-07-25 19:04 ` [3/3] POHMELFS high performance network filesystem. POHMELFS core Evgeniy Polyakov
2008-07-25 19:40 ` [0/3] POHMELFS high performance network filesystem. IPv6 support, documentation update Jamie Lokier
2008-07-25 20:35 ` Evgeniy Polyakov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080725203512.GA10873@2ka.mipt.ru \
--to=johnpol@2ka.mipt.ru \
--cc=jamie@shareable.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).