[Top] [All Lists]

Re: [DMAPI] code error in dm_ip_to_handle()

To: Dean Roehrich <roehrich@xxxxxxx>
Subject: Re: [DMAPI] code error in dm_ip_to_handle()
From: Aurelien Degremont - Stagiaire <degremont@xxxxxxxxxxx>
Date: Thu, 12 May 2005 15:15:47 +0200
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20050511204538.831CA4FE8A@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <20050511204538.831CA4FE8A@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225
Dean Roehrich a écrit:
Maybe we should throw out struct dm_fsfid and just use struct dm_fid?  Then
XFS, for example, would have to translate its fid_t into a struct dm_fid on
its own and DMAPI shouldn't have to guess about how they match up.  I
wonder how that would work?

We must wondered what are the purpose of each structure ?
- dm_fsfid : Just a **opaque** buffer. The FS is responsible for what it put there. But with this structure, DMAPI **could not know the meaning of the buffer content**. It must use it as it is. It is just an ID it will deal with using fh_to_inode(), mainly. - dm_fid : An file identifier using VFS information : its inode and a generation number. The content of the ID is known and so DMAPI could use this ino and gen number if needed. (What's the purpose of the dm_fid_len and dm_fid_pad field ? Something about alignment or data size ? Maybe we could get rid of them ?)

The question is : Does DMAPI need the inode number of the filehandles ?
After some searches it seems this data is only used in dmapi_session.c, when dealing with hash_event. I don't know the purpose of them. But concerning repeated_event(), it looks like the inode number is only used in order to compare 2 handles. I think, this comparison must be done using the whole structure (memcmp) or at least using the ino AND the gen number. The ino number is not enough.

So, if the inode number is used somewhere in DMAPI, the filehandle must contain the inode number or the FS must provided a way to fetch the inode number from the filehandle. I think the first way is easier. So it seems we could indeed replace the dm_fsfid by dm_fid. So the FS will just set the inode number and the gen number ? Are the len useless ? I think so. So, if we use this solution, do we really need a specific function in the fs-side ? This information could be automatically gathered from the VFS layer in the DMAPI call like dm_ip_to_handle(). If we choose the solution where the structure has an 'ino' field, the FS must set the ino inside, I don't want that the FS could set whatever it wants in dm_fid.

So :
 - Replace the dm_fsfid by dm_fid : Yes
 - Remove the useless field of this structure
 - Automatically fill it in DMAPI. Remove the corresponding dmapiops.


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