All of lore.kernel.org
 help / color / mirror / Atom feed
From: Evgeniy Polyakov <zbr@ioremap.net>
To: Yehuda Sadeh Weinraub <yehudasa@gmail.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [4/9] pohmelfs: directory operations.
Date: Wed, 14 Jan 2009 04:07:19 +0300	[thread overview]
Message-ID: <20090114010719.GC1705@ioremap.net> (raw)
In-Reply-To: <a37615150901131643m3e46d82albba5366533671b40@mail.gmail.com>

Hi.

On Tue, Jan 13, 2009 at 04:43:30PM -0800, Yehuda Sadeh Weinraub (yehudasa@gmail.com) wrote:
>   I've played a bit with pohmelfs and it looks very nice. Specifically
> I was very happy with the easy configuration on both the server and
> the client.

Thanks a lot for giving it a try!

> I understand that you manage the metadata operations asynchronously.
> How do you handle multiple clients in pohmelfs? Any specific locking?

There is a cache coherency protocol which is managed by the server, so
effectively every access requests a lock and if another client
influences the object, server will ask the first one to flush its
changes to the server which will then be sent to the second client after
it gets the lock. Locks are cached and not requested again when new
operation happens, it will be requested only if server requested to drop
the lock.

> I did have some problems. I was trying to run dbench and it failed.
> Also I understand that you haven't implemented all vfs interface yet
> (chmod, chown, etc.). I was looking at the following code (more of at
> the comments), and it explained some strange stuff that I had seen:

They should be implemented already in the change attribute code.
Attribute changes are flushed at writeback time or on server's demand.

I will try to reproduce the problem locally, thanks for the report.
Can you provide the output of the command, its parameters and the dmesg?

> I understand that you handle metadata operations locally, and for
> example when doing mkdir or creating a file, the file/directory is
> created locally, the inode is set dirty and when a writeback occurs
> everything is syncronized to the server. Isn't there some problem in
> cases where there are more than one client operating on the same
> directory with the same filename then? Moreover, it is possible that
> client A creates a file and client B creates a directory with the same
> name. Am I missing something, or is that the intended design?

There are distributed locks used in the POHMELFS, and appropriate
protocol maintains coherent cache on all the clients.

In the example you showed, the first client will grab the parent
directory lock, create a file there and then flush it to the server when
the second client starts an operation. It will then detect that there is
a file with given name and file the processing (or will overwrite its
content, depending on the application of course).

-- 
	Evgeniy Polyakov

  reply	other threads:[~2009-01-14  1:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-14  0:43 [4/9] pohmelfs: directory operations Yehuda Sadeh Weinraub
2009-01-14  1:07 ` Evgeniy Polyakov [this message]
2009-01-14  1:28   ` Yehuda Sadeh Weinraub
2009-01-14  1:31     ` Evgeniy Polyakov
  -- strict thread matches above, loose matches on Subject: below --
2009-02-09 14:02 [0/9] pohmelfs for drivers/staging Evgeniy Polyakov
2009-02-09 14:02 ` [1/9] pohmelfs: documentation Evgeniy Polyakov
2009-02-09 14:02   ` [2/9] pohmelfs: configuration interface Evgeniy Polyakov
2009-02-09 14:02     ` [3/9] pohmelfs: crypto processing Evgeniy Polyakov
2009-02-09 14:02       ` [4/9] pohmelfs: directory operations Evgeniy Polyakov
2008-12-26 14:18 [0/9] pohmelfs: The Great Southern Trendkill release Evgeniy Polyakov
2008-12-26 14:18 ` [1/9] pohmelfs: documentation Evgeniy Polyakov
2008-12-26 14:18   ` [2/9] pohmelfs: configuration interface Evgeniy Polyakov
2008-12-26 14:18     ` [3/9] pohmelfs: crypto processing Evgeniy Polyakov
2008-12-26 14:18       ` [4/9] pohmelfs: directory operations 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=20090114010719.GC1705@ioremap.net \
    --to=zbr@ioremap.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=yehudasa@gmail.com \
    /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.