I'm still working on DMAPI code and I found a problem in dm_ip_to_handle() function. In fact, the problem is not specific to this function, I just found it here. To sum up, I found, in the XFS+DMAPI
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
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 shoul
The dm_fid_len field is used to distinguish between filesystem handles and file handles. That has to stay in place. I could agree to that, but what do we give to the hash function? It is the FS whic
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
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 ro
Dean Roehrich a écrit: 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
Dean Roehrich a écrit: What's the difference between dm_path_to_fshandle("/") hlen = DM_FSHSIZE dm_path_to_handle("/") ? hlen = DM_HSIZE(handle) Both use dm_ip_to_handle(), and get a full filehandl
Dean Roehrich a écrit: 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 cod
dm_ip_to_handle() and ->inode_to_fh() always return a filehandle. It looks like this no longer behaves the same as the original Irix code. On Irix, if dm_handle_to_ip() is going to call VFS_ROOT the
To sum up : - inode_to_fh() only need to fill a dmfsfid (currently :)) with something like that : fid.dm_fid_len = sizeof(dm_fid_t) - sizeof(fid.dm_fid_len); fid.dm_fid_pad = 0; fid.dm_fid_gen = ip->
Okay. No. fh_to_inode() doesn't have to modify the dm_fsfid at all. It just needs to check that it refers to a valid inode, and then it needs to return that inode. Dean
Dean Roehrich a écrit: - fh_to_inode() must test the fid_len field and return the root inode number if its value is zero. No. fh_to_inode() doesn't have to modify the dm_fsfid at all. It just need
I've been using your patch today. So far it's good. Here's the rest of it, to completely remove dm_fsfid. Do these dm_copyin_handle() changes look right to you? Dean Index: lbs-a/linux/linux/fs/dmap
Dean Roehrich a écrit: From: Aurelien Degremont - Stagiaire <degremont@xxxxxxxxxxx> Here is a very small patch that change the parameter of fh_to_inode() and inode_to_fh(). I just replace the dm_fs
Dean Roehrich a écrit: From: Aurelien Degremont - Stagiaire <degremont@xxxxxxxxxxx> Here is a very small patch that change the parameter of fh_to_inode() and inode_to_fh(). I just replace the dm_fs
Thanks, I'll get this in today. I have to jump ahead. I need to have one struct filesystem_dmapi_operations per mounted filesystem to solve a problem I'm dealing with now, and I have to do it withou