Punkt połączenia NTFS z dysku twardego na dysk SSD, czy spowoduje to wąskie gardło wydajności? (przeniesienie gry Steam)

Czy punkt połączenia NTFS między dyskami twardymi może powodować wąskie gardło? A może skrzyżowanie zostanie zapisane w pamięci podręcznej?

W szczególności chcę zainstalować Steam na magnetycznym dysku twardym. Oznacza to, że wszystkie gry zostaną tam zainstalowane. Aby skorzystać z mojego dysku SSD, połączę gry, w które gram aktywnie, z katalogu Steam na dysku twardym do dysku SSD.

Zastanawiałem się, czy to spowoduje problem z wydajnością. Czy za każdym razem, gdy gra uzyskuje dostęp do pliku, musi odczytać dysk twardy, odczytać punkt połączenia, rozwiązać nową ścieżkę na dysku SSD, a następnie uzyskać prawdziwy plik? A może system operacyjny buforuje to przekierowanie, aby kara za wydajność była trafiana tylko za pierwszym razem?

Dzięki!

— ddtemplar
źródło

Definicja punktu połączenia jest przechowywana bezpośrednio w odpowiednim wpisie MFT. Ponieważ MFT jest buforowany w pamięci, nie spodziewałbym się, że dostęp do dysku twardego będzie możliwy podczas pracy z połączonym katalogiem.

— Gene

Dzięki! Nie będę się tym zbytnio przejmował, chyba że zacznę zauważać dziwne spowolnienia.

— ddtemplar

Nawet jeśli trzeba było uzyskać dostęp do dysku twardego, aby odczytać punkt połączenia, jest niewielki - odczyt skończyłby się niemal natychmiast i wystarczyłby tylko raz, ponieważ zostałby zapisany w pamięci podręcznej.

— Adambean

Uwaga z jednej strony: Jeśli zainstalujesz aplikację Steam na dysku SSD, nadal możesz zmienić miejsce instalacji gry na Steam bez połączenia.

— cybernard

Najprawdopodobniej nie, to nie będzie wąskie gardło. Jest pewien narzut związany z połączeniami NTFS, ale w twoim scenariuszu powinno to być nieistotne.

Możesz pozbyć się narzutów, fizycznie przenosząc dane na dysk SSD i w ogóle nie używając skrzyżowań (co wydaje mi się być głównym problemem twojego pytania), ale wątpię, czy mógłbyś zmierzyć różnicę.

Gdzie są przechowywane i buforowane węzły?

Połączenia są rodzajem punktów ponownej analizy, które wszystkie są przechowywane w $Extend\$Reparse metapliku (innym bardziej znanym metaplikiem jest $MFT).

Gdy do pliku lub katalogu jest powiązany punkt ponownej analizy, NTFS tworzy atrybut o nazwie $Reparsepunktu ponownej analizy. Ten atrybut przechowuje kod ponownej analizy i dane. Aby system plików NTFS mógł łatwo zlokalizować wszystkie punkty ponownej analizy na woluminie, w pliku metadanych o nazwie \$Extend\$Reparseznajdują się wpisy, które łączą plik punktu ponownej analizy i numery pozycji katalogu MFT z powiązanymi z nim kodami ponownej analizy. NTFS sortuje wpisy według numeru wpisu MFT w $Rindeksie.

źródło: Inside Win2K NTFS, część 1 autorstwa Marka Russinovicha

Ponownie wykonaj schemat

źródło: Inside Win2K NTFS, część 1 autorstwa Marka Russinovicha

Pojawiły się komentarze, że skrzyżowania są przechowywane w MFT i że MFT jest buforowane. Teraz, gdy wiemy, gdzie są przechowywane skrzyżowania, potrzebowałbym wiarygodnego źródła do obsługi roszczenia o buforowanie; których nie mogłem znaleźć.

Więc nie wiem, ale nie sądzę, żeby to miało znaczenie.

Czy istnieje udokumentowany scenariusz, w którym skrzyżowanie między dyskami zmniejszyło wydajność?

Tak, ARF ma takie problemy . Benchmark porównywał wsadowo usuwanie małych plików, a kiedy operacja była przeprowadzana na skrzyżowaniu, czynnikiem ograniczającym nie było już IO (zgodnie z oczekiwaniami), ale procesor. Ten test porównawczy został również szczegółowo omówiony na GitHub .

— Vlastimil Ovčáčík
źródło