"J. Bruce Fields" <bfie...@fieldses.org> writes: >> > There is some unclear thing. >> > When I see first mail, I think maybe you don't want to use i_pos for >> > inode->ino. >> > FAT allocate inode->ino from i_unique on server side and If NFS client >> > use i_pos for inode->ino in fat_get_attr, inode numbers on each >> > client/server will still be mismatched. >> > >> > Would you plz give me hint ? >> >> ->i_ino is long. It can't hold i_pos fully on 32bit arch, so we can't >> use ->i_no to store i_pos, and changing ->i_ino is unnecessary. If >> getattr() returned i_pos as ino, nobody see ->i_ino anymore except >> internal of kernel. > > The NFS server must always return the same inode number for the same > filehandle. To do otherwise is a bug. > >> Furthermore I think there is no issue even if server and client didn't >> have same ino. Because client just uses FH (nfs4 seems to be using >> stat.ino though). > > The client may expose a different inode number to userspace, but it's > probably the server-provided inode number that it's checking. > > (And even if the Linux client didn't currently happen to do that check, > this would still be a bug.)
In this context, inode number != inode->i_ino, right? It should be kstat.ino, and in FAT case, it will return i_pos always. Otherwise 64bit inode number would not work. So, I think we are doing right thing for now. Anyway, thanks for your review. -- OGAWA Hirofumi <hirof...@mail.parknet.co.jp> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/