Re: The bug of iput() removal from flusher thread?

[Jan Kara <jack@suse.cz>]

On Mon 19-11-12 17:56:22, OGAWA Hirofumi wrote:
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
> 
> > Hi,
> >
> > In 169ebd90131b2ffca74bb2dbe7eeacd39fb83714 commit, writeback doesn't
> > __iget()/iput() anymore.
> >
> > This means nobody moves the inode to lru list. I.e.
> >
> > 	new_inode()
> > 	dirty_inode()
> > 	iput_final()
> > 		/* keep inode without adding lru */
> > 	flush indoes
> >         /* clean inode is not on lru */
> >
> > I noticed this situation in my FS though, I think the same bug is on all
> > FSes of linus tree too, after this commit.
> >
> > Am I missing the something?
> 
> This seems to be reproducible by the following,
> 
> #!/bin/sh
> 
> for i in $(seq -w 1000); do
> 	for j in $(seq -w 1000); do
>         	for k in $(seq -w 1000); do
>                 	mkdir -p $i/$j
>                         echo $i/$j/$k > $i/$j/$k
>                         echo 2 > /proc/sys/vm/drop_caches
>                 done
>         done
> done
> 
> Some inodes never be reclaimed, and ls -l frees those inodes (stat(2)
> does iget/iput).
  So looking into the code I agree we won't put inode into the LRU when it
is dirty or under writeback and after writeback is done it won't happen
either. That's certainly a bug. But I have hard time reproducing your
results because on my kernels even dcache doesn't get shrunk thus inodes
are pinned in memory by it. Not sure what's going on yet but I'll
investigate. Thanks for report!

								Honza
  
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR