>From: Aurelien Degremont - Stagiaire <degremont@xxxxxxxxxxx>
>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 dm_fid_len field is used to distinguish between filesystem handles and
file handles. That has to stay in place.
>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?
>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.
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'
field.
Dean
|