> On Oct 2, 2015, at 9:57 AM, Leonid Fedorenchik <leonid.fedorenchik@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, 1 Oct 2015 22:54:08 +0000 > "Kornievskaia, Olga" <Olga.Kornievskaia@xxxxxxxxxx> wrote: > >> [...] >> >> In NFS development, we’ve been seeing a race between reopening of the same file and evict inode code and unable figure out how to prevent such race. When file is opened for the first timed and then closed. As the last reference is dropped and iput_final() calls evict() which will call filesystem specific evict_inode() code. As that’s happening a new open for the same file is happening and causes problems. > Recently we encountered similar situation with NFS, that is, after > evict_inode() & iget_locked() we were getting the same inode (same > i->i_ino) and without I_NEW bit set. Thanks for the comment! When I tried to print inode state flags in the NFS code for opening a file I’ve never had “I_NEW” set. Not sure why. > >> >> Also can somebody suggest how to debug VFS code, as putting printks generates output for the local filesystem code as well. > You can call printk() only if current process is "nfsd" (at least, > that is what we did). > Thanks for the suggestion. I’ll try that. Again a general question to the community about inodes and eviction. I was under the general impression that when the file is closed the inode sticks around just in case the file is reopened again. Then when resources are constrainted some background thread evicts unused inodes. Is that understanding correct? In that case what is that background process name? >> >> Thank you. >> >> [...] > > -- > > Best regards, > Leonid Fedorenchik > > Software Engineer > Paragon Software Group > Skype: leonid.fedorenchik > http://www.paragon-software.com > ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
