[Top] [All Lists]

Re: DMAPI rights

To: Dean Roehrich <roehrich@xxxxxxx>
Subject: Re: DMAPI rights
From: "James A Goodwin" <jagoodwi@xxxxxxxxxx>
Date: Fri, 15 Feb 2002 09:06:18 -0600
Cc: linux-xfs@xxxxxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
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?


-James Goodwin
Software Engineer
IBM Global Services - Federal
Phone: (281) 336 2578
Fax: (281) 335 4231
T/L 260-2578

                      Dean Roehrich                                             
                      <roehrich@xxxxxxx        To:       James A 
                      >                        cc:       linux-xfs@xxxxxxxxxxx  
                      Sent by:                 Subject:  Re: DMAPI rights       
                      02/15/2002 08:38                                          

>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.


<Prev in Thread] Current Thread [Next in Thread>