[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: Fri, 13 May 2005 15:00:00 +0200
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20050512161213.29B464FE8A@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <20050512161213.29B464FE8A@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225

The dm_fid_len field is used to distinguish between filesystem handles and
file handles.  That has to stay in place.

Ok. I miss this.
About it, I don't understand how the dm_fid_len is filled. I don't find where in the code, you set its len to 0 when its a filesystem handle ? How do you know this ?

(But I found in xfs_dm_fh_to_inode(), where you test the fid_len)

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.

I could agree to that, but what do we give to the hash function?

I don't know the purpose of this hash function, so i couldn't help you here. But, at least, check also the i_gen number equality, or do a memcmp() between the two handle structures rather then just the ino value.

It is the FS which must convert between handles and filesystem objects, so the
handle better make sense to the FS.  Whenever DMAPI needs this conversion, it
should call to the FS.  So, no, DMAPI should not control the 'dm_fid_ino'

Ok, so let the FS free of whatever tricks it wants or needs (thinking about distributed filesystem by example...)

Ok. So, do we remove the dm_fsfid_t ? Replace it by a dm_fid as you proposed ? I think it's a good idea.


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