On jeu, 2007-03-29 at 13:59 -0600, Andreas Dilger wrote: > On Mar 29, 2007 14:17 +0200, Vincent Caron wrote: > > I just noticed that 'tune2fs -l' did not returned a "lively" updated > > information regarding the free inodes count (looks like it's always > > correct after unmounting). > > This is a bit of a defect in all 2.6 kernels. They never update the > on disk superblock free blocks/inodes information to avoid lock contention, > even if this info is available. It turns out it is okay in my case since 'df -i' reports correct numbers. > Can you please give the following patch a try? It fixes this issue, > and also makes statfs MUCH more efficient for large filesystems, because > the filesystem overhead is constant unless the filesystem size changes > and checking that for 16k groups is slow (hence hack to add cond_resched() > instead of fixing problem correctly). It has not been tested much, but > is very straight forward. > > Only the last part is strictly necessary to fix your particular problem > (setting of es->s_free_inodes_count and es->s_free_blocks_count). This > is lazy, in the sense that you need a "statfs" to update the count, and > then a truncate or unlink or rmdir in order to dirty the superblock to > flush it to disk. However, it will be correct in the buffer cache, and > it is a lot better than what we have now. We don't want a non-lazy version > anyways, because of performance. Unfortunately the problem shows on a production machine and I don't have a similar one to test properly (it's a heavy-loaded filer). BTW, if ondisk superblocks are not updated until specific events occur (umount, statfs), what is the consequence of a system crash ? Does journalization come into play (superblock=metadata?), does fsck fixes figures from other ondisk structures ? Just being curious... - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
