Actually, no. There is no general block layer cache - the closest thing is the page cache, which is at the file level.

Are you the Kent Overstreet working on bcachefs? If so, I've been watching it and looking forward for it to get into the kernel. Keep up the good work. I'll have a donation coming in a little while.

The one and only :)

I guess the real question there is, does a directory count as a file for the purposes of this discussion.

It seems necessary that the blocks storing the directory entries are cached too. Otherwise every non-existent lookup (that doesn't hit a negative dentry) would hit disk, each separately.

So yeah, the page cache is keyed by file, but the system should still cache the directory structure.

On top of the block layer cache there's also the namei cache for filename to inode lookups, I'm not sure if that covers a file not found case or just a success path, but it may apply here too.

Yep, that's called a "negative dentry".

But if a negative dentry does not yet exist, and a filename is requested for the first time, does it read from the fs?

The DDoS scenario would be doing GET requests of random nonexistent filenames. You could change the name at every step so that the check for a negative dentry is never a cache hit.

If requesting http paths result in accessing the equivalent fs paths, then yes, you can dos it. But nowadays it’s uncommon for a webserver.

Well the point under discussion is that i/o from a floppy disk is slow. Most servers have much faster disks and it'd be absurd to consider this.

Also the page/buffer cache would probably cache the FAT direntries so probably not a huge issue here.

What block layer cache?

I think I was wrong, typed too quickly. There’s (potentially) a file buffer block cache available, but that’s not for caching raw disk blocks, but filesystem blocks of content.