>From: Aurelien Degremont - Stagiaire <degremont@xxxxxxxxxxx>
>> 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)
Certainly, dm_handle_to_ip() is intended to return any type of handle,
including filesystem handles. In the case of XFS, when a filesystem handle is
requested we contruct it from the filesystem's root vnode.
I suppose dm_handle_to_ip() could be called with the handle from the mount
event. That handle would have a fid_len of 0, due to the memset() in
dm_sb_data()...the HSM would call to things like dm_get_config() and
dm_set_disp() with that handle.
>>>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.
This is going to need more work if we add the generation number to the checks,
but I agree we have a hole here.
This hash is used for async events. The best example is events from I/O via
nfsd. It may take a while for the HSM to respond to the event, and nfsd may
timeout and retry the I/O, sending another event. On a large-scale system,
this can quickly fill the dmapi queues and suck up kernel memory, especially
if the HSM is waiting on finicky tapes. To address this, we check to see if a
new async event matches one that is already in the queues, and if so, we
return it with EAGAIN and keep just the one event in the queues.
>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.
I would like to see how it works out, if you're willing to do the code.
Have you been able to try that fsid patch yet?