On Tue, 6 May 2014, Azat Khuzhin wrote: > Date: Tue, 6 May 2014 13:57:48 +0400 > From: Azat Khuzhin <a3at.mail@xxxxxxxxx> > To: Younger Liu <younger.liucn@xxxxxxxxx> > Cc: linux-ext4@xxxxxxxxxxxxxxx > Subject: Re: Why does not freeblocks number change after deleting a big file? > > On Tue, May 06, 2014 at 11:32:12AM +0800, Younger Liu wrote: > > Hi: > > Analyze ext4 filesystem with "debugfs -R "stats" <device>", > > Why does not free blocks number change after deleting a big file? > > > > The big file: > > # stat test > > file："test" > > size：290554084 blocks：567496 IO block：4096 > > > > before deleting the file "test": > > # debugfs -R "stats" /dev/sdb > > ... > > Inode count: 243593216 > > Block count: 1948728320 > > Reserved block count: 97436416 > > Free blocks: 406830314 > > Free inodes: 151667854 > > ... > > > > deleting the file "test" > > # debugfs -R "stats" /dev/sdb > > ... > > Inode count: 243593216 > > Block count: 1948728320 > > Reserved block count: 97436416 > > Free blocks: 406830314 > > Free inodes: 151667854 > > Hi, > > Seems that you are trying to do this on a mounted partition, and the > super block are not dumped to disk after every write/flush. > > You could use statfs(2) instead of debugfs/stats command, or "mount -o > remount /dev/sdb_X_" and after debugfs, this _must_ work only in case > you don't have journal. > > For more information you could look into ext4_commit_super(). Yes, it really looks like you're doing this on mounted file system. However we do not update the superblock for some of the summary statistics such as number of free blocks, inodes and so on. This is because it is recalculated from per block group descriptors when the file system is mounted, or unmounted. So when the file system is mounted debugfs is not going to give you an accurate information. You have to use something else like 'stat -f' for example. Thanks! -Lukas > > > ... > > > > Younger > > thx. > > -- > > 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 > >
