|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|
|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 ?
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' field.
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>|
|Previous by Date:||TAKE 934679 - fix some more compiler warnings in the vnode tracing code, Christoph Hellwig|
|Next by Date:||Re: [DMAPI] code error in dm_ip_to_handle(), Dean Roehrich|
|Previous by Thread:||Re: [DMAPI] code error in dm_ip_to_handle(), Dean Roehrich|
|Next by Thread:||Re: [DMAPI] code error in dm_ip_to_handle(), Dean Roehrich|
|Indexes:||[Date] [Thread] [Top] [All Lists]|