All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
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: Fri, 25 Jul 2008 20:40:34 +0100	[thread overview]
Message-ID: <20080725194033.GA16133@shareable.org> (raw)
In-Reply-To: <20080725190134.GA30685@2ka.mipt.ru>


>From the design notes,
> POHMELFS got full data and metadata cache coherency support.
>
> It was rather simple task due to async event processing support.
>
> Each time client creates, reads or writes object to server,
> information about its interest is stored on server. When any other
> client updates the same object (like changing attributes or writes
> data), all interested clients get notifications with new data (new
> attributes, or in case of writing possibly new size and flag, which
> page has to be fetched from the server, since it is not valid
> anymore). Writing happens during writeback as before, so commands like
> "echo Some_message > /mnt/file" immediately syncs size of the file to
> zero and after some time writes there actual data, when system will
> decide to start writeback.

I'm just going by what the notes say, which don't seem very clear.

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.

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?

Thanks,
-- Jamie

  parent reply	other threads:[~2008-07-25 19:40 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 ` Jamie Lokier [this message]
2008-07-25 20:35   ` [0/3] POHMELFS high performance network filesystem. IPv6 support, documentation update Evgeniy Polyakov

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=20080725194033.GA16133@shareable.org \
    --to=jamie@shareable.org \
    --cc=johnpol@2ka.mipt.ru \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.