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.