On Mon 19-11-12 17:56:22, OGAWA Hirofumi wrote: > OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> 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@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
