> -----Original Message----- > From: kernelnewbies-bounce@xxxxxxxxxxxx > [mailto:kernelnewbies-bounce@xxxxxxxxxxxx] On Behalf Of > prasanna wakhare > Sent: Thursday, December 02, 2004 10:42 PM > To: kernelnewbies@xxxxxxxxxxxx > Subject: RE: Linux VFS and inode numbers in the inode list > > Hi, > > > > Please help me with this question. > > > > I was working with Certain NFS server > > implimentations which returns > > 64bit fileids. Linux seems to be converting these > > 64 bit > > file ids to > > 32bit inode numbers before storing it in the inode table (Inode > > information is filled by lookup inode operation, which calls > > nfs_lookup, which then calls nfs_fhget). > > > > Because of this converstion from 64 bit to 32 bit, there could be > > duplicate inode numbers in VFS inode list ( Do not doubt > it, I have > > seen it practically and bit difficult to explain, but it happens). > > > > Will the system run in to some issues if there is duplicate inode > > numbers ?. > > > > As far as I know, all the access to inode list is through dentry > > cache. So it should not be a problem, I guess. Is there any kernel > > functions which purely works with inode numbers to locate > the inode > > details from the inode list ? > > > > Any ideas ? > > > From basic thory of filesystem inode number is unique and are > only means to access from storage device and populated in > in-core inode structure(BACH), And Mainly, Even though all > access are through dentry structure, and you also given > reference of nfs_lookup, dentries are negative when first > time lookup are fired on files in nfs_lookup. > This means there are no inodes pointed by this dentry. > And nfs or any filesystem has first have to iget it, and > which is only possible if unique inode number is given,and > that's what nfs does(i guess) or in genral any filesystem > does, After iget it attaches the inode to dentry and make > that dentry positive. > So these numbers are unique.And you never found them > duplicate inside any filesystem. Thanks for your answer. It makes things more clear. But trust me, with NFS, you could have duplicate inodes number in the in-core inode table. I mean, same inode number with same super block pointer. I am wondering where this would create a problem. If you are really keen, I can explain the situation where we could have duplicate inodes. Regarding, iget. Nfs_lookup does not use iget. But it uses iget4. It compares, inode numbers, super block, NFS file handles and NFS fattr structure of the file before returning the inode from the cache. If it could not find an inode in the cache, it will create a new one. Do you know what are the other places ( Like you mentioned iget ) where the inode numbers are important ? Remember in NFS, the actual file system in the disk on the server will not have duplicate inode numbers ... I am discussing about the inode number in the VFS layer of the client. > > Thanks > Prasanna > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - Helps protect you from nasty viruses. > http://promotions.yahoo.com/new_mail > > -- > Kernelnewbies: Help each other learn about the Linux kernel. > Archive: http://mail.nl.linux.org/kernelnewbies/ > FAQ: http://kernelnewbies.org/faq/ > > -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
