2

I have a remote block device with the test ext4 filesystem image. On the iSCSI initiator side, I have this device detected as let's say /dev/sdb. I am not mounting this filesystem but instead I use TheSleuthKit (TSK) forensic tool fls to read the content of my data.

I notice that for the second run the execution time indeed is faster. I know about the page cache and that to bypass it I should use Direct-IO. However, I was convinced this will not be the case for the iSCSI.

If the device is being modified by another node, there is no way for my client to see it if it has this entry cached. So it simply means - inconsistency issues. How can I ensure my reads will always go to the "source" ? Is there any parameter I can set to flush read cache periodically ?(echo 3 > /proc ... is not an option).

Improve this question

1 Answer 1

Reset to default
1

Yes, there is a block device read buffer cache -- bcache -- which caches blocks previously read.

If you do not want this behavior, you can open the block device with O_DIRECT flag.

Improve this answer
1
  • Actually as I understand, bcache is not some default cache, it's a thing one have to configure explicitly. So it's unlikely to be the OP's problem. I'm gonna dump some of the research I've done here in comment too: after a discussion on #kernel-newbies IRC I've got an impression that nowadays (which is 4 years since the question posted) there's no block-device level cache. There's VFS-level cache, but it's unused if you don't have an FS over the block device. There's also /sys/block/sdX/queue/write_cache file, but whether it's a software or hw cache is unclear from the current docs.
    – Hi-Angel
    Commented Mar 26, 2020 at 14:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .