linux-ext4 - Re: Why doesn't disk io occur to read file system metadata despite clearing dentry and inode with drop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 17 Oct 2019 17:32:17 +0200
From:   Jan Kara <jack@...e.cz>
To:     Daegyu Han <hdg9400@...il.com>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: Why doesn't disk io occur to read file system metadata despite
 clearing dentry and inode with drop_cache command?

Hello,

On Wed 11-09-19 15:27:07, Daegyu Han wrote:
> I am confused about "echo # >/proc/sys/vm/drop_caches" and blockdev
> --flushbufs.  According to OSStep book written by Remzi,If the target
> inodes are not cached in memory, disk IO should be occur to readthe
> inode, which will make a dentry data structure on memory.  To my
> knowledge, echo 3 >/proc/sys/vm/drop_caches is to drop(clear) page
> cahche, inodes and dentry. I have experimented with blktrace to figure
> out whether disk io is really occurring to read the inode.
> 
> 1. echo 3 > /proc/sys/vm/drop_caches
> However, there is no disk io to read inode. I can only see the disk io
> to read 16KB data block.
> 2. echo 3 > /proc/sys/vm/drop_caches` and `blockdev --flushbufs
> /dev/nvme0n1I found block access (+8(512*8=4KB)) to read inode.
> 
> A quick look at how blockdev --flushbufs works in the kernel code shows
> that it clears the superblock.  Why doesn't disk io occur to read inodes
> with drop_cache alone?  The kernel book called ULK says that inodes and
> superblocks are cached in buffer-cache.Is this the reason for this?  I
> infer as follows:Is the buffer_head data structure not flushed to disk by
> drop_cache alone because the storage device is still mapped in memory?

Yes, I guess that's what happened. Note that drop_caches drop only clean
and unreferenced inodes, dentries & page cache. So if the inode is dirty
(e.g. due to atime update pending), drop caches won't free it. Another
effect may be that something (e.g. the jbd2 journal) holds onto the buffer
caching the inode table block with the inode.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR