undefined | Better HN

0 pointsp_ing1mo ago0 comments

NTFS will perform directory B+-tree lookups (this is where it walks the path) until it finds the requested file. The Cache Manager caches these B+-trees.

From there, it hits the MFT, finds the specific record for the file, loads the MFT record, and ultimately returns the FILE_OBJECT to the I/O Manager and it bubbles up the chain back to (presumably) Win32. The MFT is just a linear array of records, which include file and directories (directory records are just a record with directory = true, essentially).

Obviously simplified. Windows Internals will be your friend, if you want to know more.

0 comments

mananaysiempre1mo ago

Thanks for the explanation! Linux, meanwhile, will[1] in the normal case walk a sequence[2] of hash tables (representing incomplete but up-to-date views of directories) before hitting the filesystem’s vtable or the block I/O layer at all, and on the fast path[3] taking no locks other than the RCU read lock.

[1] https://www.kernel.org/doc/html/latest/filesystems/path-look...

[2] I was under the impression that it could look up an entire path at once when I wrote my grandparent comment; it seems I was wrong, which on reflection makes sense given you can move directories.

[3] https://www.kernel.org/doc/html/latest/filesystems/path-look...

Rapzid1mo ago

Heh, first I've heard of Windows Internals. New friends for The Linux Programming Interface!

p_ingOP1mo ago

Yes, won't be that quite in depth given no source code, but you can easily look up the NT4 source code on GitHub if you want to dive that deep. I would assume much of that code should still be relevant today.

Also worth tracking down a copy of the NT OS/2 Design Workbook on the web (another leak).

And Inside the Windows NT File System by Helen Custer is a very short book but describes the very early state of NTFS capabilities/functions.

j / k navigate · click thread line to collapse