You are right. Each of the 'programs' I was mentioning before will have
its own token. The dm_request_right() call simply asks the DMAPI to attach
the requested right to the token. Any subsequent call using that token
would have the right. However, I don't think it's a question of deciding
who gets to do what by looking at the rights on their token. Rather its a
question of whether or not the DMAPI will attach the requested right to
your token or not depending on what rights are attached to other tokens for
the same object. After your token has the right, you can do any operation
that the right allows.
I've taken a closer look at the XFS DMAPI code, and I think I've figured
out how it works. There are rights involved, but like you said
dm_request_right() and dm_release_right() don't attach/remove rights
to/from the caller's token. Between that and the fact that tokens
delivered with events never have rights attached, it is impossible for a
DMAPI client to ever have rights attached to his token. This means that
any DMAPI call requiring a token with rights attached must use the special
DM_NO_TOKEN (I discovered this the hard way when most calls were returning
EACCES). This way, each individual DMAPI call will acquire the appropriate
locks (tdp locks as I recall) needed to synchronize with the other DMAPI
The end result is that XFS DMAPI ensures that individual DMAPI calls will
not interfere with one another but that any further synchronization must be
taken care of at a higher level. So our new client code implements its own
locking to allow a string of DMAPI calls against a particular file while
blocking any other DMAPI calls that would modify the file or its
Do you have any idea how to fix the problem of the ne_mode field not
returned with the remove event, or is this something that I'll have to find
a workaround for?
IBM Global Services - Federal
Phone: (281) 336 2578
Fax: (281) 335 4231
<roehrich@xxxxxxx To: James A
> cc: linux-xfs@xxxxxxxxxxx
Sent by: Subject: Re: DMAPI rights
>From: "James A Goodwin" <jagoodwi@xxxxxxxxxx>
>Are you saying that rights do exist and are checked at the DMAPI level?
>so, does this mean that a DMAPI program could use rights to synchronize
>between DMAPI calls but must use some other mechanism to coordinate with
>non-DMAPI clients of the filesystem?
>Let me clarify a bit. Let's say that I have two DMAPI programs that want
>to modify the DM attributes of the same file using the dm_set_dmattr()
>call. If they both call dm_request_right() to get a DM_RIGHT_EXCL right
>the file, one will get the right while the other will block. When the
>initial program finally calls dm_release_right() the second program will
>get the DM_RIGHT_EXCL and continue. Is that correct?
No, we don't block. You just get the vn_hold/vn_rele.
The spec talks about it in terms of programs, implying processes, but it's
actually meaning tokens, right? Two tokens, referring to the same file,
rights to decide which of the tokens does, or doesn't, get to be acted on.