NTFS Junction Point from HDD to SSD, will it cause performance bottleneck? (steam game relocation)

Question

Can an NTFS Junction Point between HDDs cause a bottleneck? Or will the junction be cached in memory?

Specifically, I want to install Steam on a magnetic HDD. This means all the games will be installed there. To benefit from my SSD, I will junction point the games I am actively playing from Steam's directory on the HDD to the SSD.

I was wondering if this would cause performance issue. Every time the game accesses a file, does it need to read the HDD, read the junction point, resolve the new path on the SSD, then get the true file? Or will it the OS cache this re-direction so the performance penalty is only hit the first time?

Thanks!

Answer 1

Most likely no, it won't be bottleneck. There is some overhead associated with NTFS junctions, but in your scenario it should be negligible.

You could get rid of the overhead by physically moving the data to the SSD and not using junctions at all (which seems to be the core concern of your question to me), but I doubt you could measure the difference.

Where are the junctions stored and cached?

Junctions are type of reparse points which are all stored in $Extend\$Reparse metafile (another more famous metafile is the $MFT).

When a file or directory has a reparse point associated with it, NTFS creates an attribute named $Reparse for the reparse point. This attribute stores the reparse code and data. So that NTFS can easily locate all reparse points on a volume, a metadata file named \$Extend\$Reparse stores entries that connect the reparse point file and directory MFT entry numbers to their associated reparse point codes. NTFS sorts the entries by MFT entry number in the $R index.

source: Inside Win2K NTFS, Part 1 by Mark Russinovich

Reparse diagram

source: Inside Win2K NTFS, Part 1 by Mark Russinovich

There were comments that junctions are stored in MFT and that MFT is cached. Well now, when we know where the junctions are stored, I would require credible source to support the caching claim; which I couldn't find.

So I don't know, but I don't think it matters.

Is there a documented scenario when cross disk junction decreased performance?

Yes, ARF has run into issue like this. He was benchmarking batch deletion of small files, and when the operation was conducted across junction, the limiting factor was no longer IO (as expected) but the CPU. This benchmark was also discussed in detail on GitHub.