Mailing List Archive

On Mon, Jan 24, 2000 at 09:20:00AM -0700, Peter J. Braam wrote:
> Hi,
>
> A number of people made suggestions about the DLM that I'd like to
> collect. Here are a few things that I remember:
>
> 1. inline data passing with requests. Ken can you remind me what you
> wanted.

What we were talking about was a flag that was passed in when a machine
enqueues a lock request. The flag says "I would like to have the data
protected by this lock being transmitted to me through an out-of-bounds
protocol."

This flag is passed in the Blocking Callback to the the clients holding the
lock. If one of those clients is caching the data, it can send the data
directly to the machine who is asking for it.

The machines holding the lock still need to flush their dirty data back to the
shared disk, but the new holder doesn't need to read the data off the disk.
The idea is that it should speed things up.

Or at least that's what I was thinking of. Maybe Stephen had a different
idea?

> 2. Extents. Clearly file systems need extent locks of some sort to deal
> with flock etc. Both the VAX clusters and IBM 390 lock manager
> architectures regard this as an application of the DLM. The VAX clusters
> have an extent cache for this purpose. I think that is the right
> approach. The DLM should have simple primitives, and we should make this
> an application.
>
> 3. IBM programmers guide. Can someone give me a URL to it?
>
> Were there other comments?
>
> - Peter -
>
>
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.tummy.com
> http://lists.tummy.com/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

--
Ken Preslan <kpreslan@zarniwoop.com>

Ken Preslan wrote:
>
> On Mon, Jan 24, 2000 at 09:20:00AM -0700, Peter J. Braam wrote:
> > Hi,
> >
> > A number of people made suggestions about the DLM that I'd like to
> > collect. Here are a few things that I remember:
> >
> > 1. inline data passing with requests. Ken can you remind me what you
> > wanted.
>
> What we were talking about was a flag that was passed in when a machine
> enqueues a lock request. The flag says "I would like to have the data
> protected by this lock being transmitted to me through an out-of-bounds
> protocol."
>
> This flag is passed in the Blocking Callback to the the clients holding the
> lock. If one of those clients is caching the data, it can send the data
> directly to the machine who is asking for it.
>
> The machines holding the lock still need to flush their dirty data back to the
> shared disk, but the new holder doesn't need to read the data off the disk.
> The idea is that it should speed things up.

At the Durham meeting, I believe we thought what we wanted was a
"request value block", send with the request and along with the blocking
call. It needs to be an opaque value, interpreted as private data between
the requester and the lock holder. I don't believe we had any conclusion
about whether it should be fixed length data or variable length data. The
contents of this opaque could include the flag mentioned above, or the flag
value could be a separate piece of data. In either case, you need the
opaque to provide the adress of the block destination in the requestor in
some form or another. There really isn't any out of band place you can
put it that won't compromise the latency a lot.

It is simplest to do the buffer flush, as mentioned, but there are ways
to keep that from being necessary. One could look at the whole CFS space
as a single large buffer cache, with one single dirty block floating around.
It is tricky to arrange for it to get written "often enough", but that does
not necessarily mean it gets flushed every time it leaves a node.

-dB

"Peter J. Braam" wrote:

> 2. Extents. Clearly file systems need extent locks of some sort to deal
> with flock etc. Both the VAX clusters and IBM 390 lock manager
> architectures regard this as an application of the DLM. The VAX clusters
> have an extent cache for this purpose. I think that is the right
> approach. The DLM should have simple primitives, and we should make this
> an application.

If you mean: locking extents is invisible to the DLM, and is a problem
for the FS as an application using the DLM, I agree.


> 3. IBM programmers guide. Can someone give me a URL to it?

Volker was promising this. I couldn't find it when I looked over the
weekend.

-dB

On Mon, 24 Jan 2000, David Brower wrote:

> > 3. IBM programmers guide. Can someone give me a URL to it?
>
> Volker was promising this. I couldn't find it when I looked over the
> weekend.
>
Oops, I just sent it to Peter "privately." Forgive me please.

Here we are:

http://www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/aixgen/hacmp_index.html

There are several books available; the one I was referring to is titled

"HACMP for AIX, Programming Locking Applications"

Sorry again. Won't happen again :-)

> -dB
>
Volker

--
Volker Wiegand Phone: +49 (0) 6196 / 50951-24
SuSE Rhein/Main AG Fax: +49 (0) 6196 / 40 96 07
Mergenthalerallee 45-47 Mobile: +49 (0) 179 / 292 66 76
D-65760 Eschborn E-Mail: Volker.Wiegand@suse.de
++ Only users lose drugs. Or was it the other way round? ++

Hi,

On Mon, 24 Jan 2000 12:05:45 -0600, Ken Preslan <kpreslan@zarniwoop.com>
said:

>> 1. inline data passing with requests. Ken can you remind me what you
>> wanted.

> What we were talking about was a flag that was passed in when a
> machine enqueues a lock request. The flag says "I would like to have
> the data protected by this lock being transmitted to me through an
> out-of-bounds protocol."

> This flag is passed in the Blocking Callback to the the clients
> holding the lock. If one of those clients is caching the data, it can
> send the data directly to the machine who is asking for it.

> The machines holding the lock still need to flush their dirty data
> back to the shared disk, but the new holder doesn't need to read the
> data off the disk. The idea is that it should speed things up.

> Or at least that's what I was thinking of. Maybe Stephen had a
> different idea?

I don't think we should mandate the way clients communicate with each
other for this. All I think we need to do is to allow a lock request to
supply an arbitrary Request Value Block (analogous to the existing Lock
Value Block), and for that request to be provided to blocking callbacks
triggered by that request.

--Stephen

Agree.

- Peter -

On Fri, 28 Jan 2000, Stephen C. Tweedie wrote:

> Hi,
>
> On Mon, 24 Jan 2000 12:05:45 -0600, Ken Preslan <kpreslan@zarniwoop.com>
> said:
>
> >> 1. inline data passing with requests. Ken can you remind me what you
> >> wanted.
>
> > What we were talking about was a flag that was passed in when a
> > machine enqueues a lock request. The flag says "I would like to have
> > the data protected by this lock being transmitted to me through an
> > out-of-bounds protocol."
>
> > This flag is passed in the Blocking Callback to the the clients
> > holding the lock. If one of those clients is caching the data, it can
> > send the data directly to the machine who is asking for it.
>
> > The machines holding the lock still need to flush their dirty data
> > back to the shared disk, but the new holder doesn't need to read the
> > data off the disk. The idea is that it should speed things up.
>
> > Or at least that's what I was thinking of. Maybe Stephen had a
> > different idea?
>
> I don't think we should mandate the way clients communicate with each
> other for this. All I think we need to do is to allow a lock request to
> supply an arbitrary Request Value Block (analogous to the existing Lock
> Value Block), and for that request to be provided to blocking callbacks
> triggered by that request.
>
> --Stephen
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.tummy.com
> http://lists.tummy.com/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>