Dlaczego rozszerzone atrybuty mogą spowalniać migrację plików w NAS?

Rozszerzone atrybuty mogą spowolnić migrację plików na NAS, gdy ich zachowanie wymaga powtarzającej się pracy z metadanymi dla każdego pliku. Atrybuty są zwykle małe, ale narzędzie migracyjne może nadal potrzebować je odkryć, odczytać, zmapować, przesłać, odtworzyć, a czasem zweryfikować. W całej strukturze katalogów zawierającej tysiące plików ta praca na obiekt może stać się zauważalna, nawet gdy przez sieć przechodzi niewiele danych atrybutów.

Spowolnienie jest warunkowe. Duża liczba małych plików jest już kosztowna do utworzenia i katalogowania, niezależnie od xattrs. Opóźnienia protokołu, aktualizacje katalogów, uprawnienia, indeksowanie, operacje I/O na dysku i zachowanie aplikacji mogą powodować podobne objawy. Rozszerzone atrybuty należy więc traktować jako dodatkowy koszt migracji, a nie jako jedyną przyczynę wolnego kopiowania na NAS.

Co rozszerzony atrybut dodaje do kopiowania pliku?

Kopiowanie pliku zwykle obejmuje dane oraz podstawowe metadane, takie jak rozmiar, znaczniki czasu, właściciel i uprawnienia. Rozszerzone atrybuty, zwane powszechnie xattrs, dołączają dodatkowe metadane w formie nazwa-wartość do pliku lub katalogu. Linux używa oddzielnych przestrzeni nazw dla danych użytkownika, etykiet bezpieczeństwa, zaufanych atrybutów oraz obiektów systemowych, takich jak listy kontroli dostępu. Model rozszerzonych atrybutów Linux zauważa również, że limity systemu plików mogą się różnić.

Zachowanie może wymagać operacji wykraczających poza kopiowanie danych. Narzędzie może wymieniać nazwy atrybutów, pobierać ich wartości, decydować, czy miejsce docelowe obsługuje każdą przestrzeń nazw, a następnie ustawiać akceptowalne wartości na nowym obiekcie. Linux udostępnia listowanie, odczyt i zapis przez odrębne wywołania systemowe xattr. To nie oznacza stałej liczby żądań sieciowych, ale pokazuje, że obsługa atrybutów ma osobną ścieżkę przetwarzania.

Praktyczny koszt zależy od implementacji. Klient może buforować, łączyć, pomijać operacje lub wykonywać je równolegle, podczas gdy serwer może przechowywać atrybut inline lub w innej strukturze metadanych. Istotne rozróżnienie dotyczy bajtów i obiektów: atrybut może zawierać tylko kilka bajtów, ale nadal wymagać osobnej decyzji dla każdego pliku, który go posiada.

Dlaczego liczba plików ma większe znaczenie niż rozmiar atrybutów?

Jeden plik o rozmiarze 50 GB to zasadniczo jeden obiekt z długim strumieniem danych. Ta sama pojemność podzielona na zdjęcia, dokumenty, pliki źródłowe i struktury pakietów może obejmować setki tysięcy obiektów. Każdy obiekt docelowy musi zostać utworzony i wpisany do katalogu, zanim zostanie rozważone opcjonalne zachowanie metadanych.

To tworzy dwie warstwy narzutu. Podstawowa praca z małymi plikami obejmuje otwieranie plików, alokację rekordów, aktualizację katalogów, ustawianie standardowych metadanych i zamykanie uchwytów. Zachowanie xattr może dodać enumerację atrybutów i ich odtwarzanie. Jeśli atrybuty wymagają tłumaczenia lub osobnej reprezentacji, ścieżka metadanych znów się wydłuża. Łączny czas może wzrosnąć, mimo że sieć przesyła bardzo niewiele dodatkowych danych atrybutów.

Z tego mechanizmu nie wynika uniwersalny mnożnik żądań. Twierdzenie takie jak „cztery żądania na atrybut” wymagałoby analizy pakietów z dokładnego klienta, wersji protokołu, narzędzia transferowego i konfiguracji serwera. Dlatego liczba plików zakończonych na sekundę i opóźnienie operacji na metadanych są bardziej użyteczne niż szacowanie wyniku tylko na podstawie rozmiaru atrybutu.

Kiedy różnice w protokole i systemie plików powodują dodatkową pracę tłumaczeniową?

Rozszerzone atrybuty nie mają jednej uniwersalnej, wieloplatformowej reprezentacji. Systemy plików Linux udostępniają przestrzenie nazw xattr, systemy plików Windows mogą udostępniać nazwane alternatywne strumienie danych, a protokoły sieciowe definiują własne opcjonalne mechanizmy. Microsoft dokumentuje obsługę alternatywnych strumieni danych jako funkcję systemu plików, podczas gdy NFSv4 definiuje rozszerzone atrybuty poprzez opcjonalne rozszerzenie xattr.

Narzędzie migracyjne musi zdecydować, co zrobić, gdy te reprezentacje nie pasują do siebie. Może zmapować nazwany strumień na docelowy xattr, zachować tylko obsługiwane przestrzenie nazw, użyć prywatnego kodowania, utworzyć inny obiekt lub pominąć metadane i zgłosić błąd. Moduł streams xattr Samby, na przykład, może przechowywać alternatywne strumienie danych SMB w POSIX xattr, ale jest to zachowanie skonfigurowanego serwera, a nie reguła dla każdego udziału SMB.

Prace związane z kompatybilnością mogą wpływać na poprawność działania, nawet gdy ich koszt wydajnościowy jest niewielki. Własność, ACL, etykiety bezpieczeństwa lub metadane aplikacji mogą nie przetrwać migracji, która kopiuje tylko dane ładunku. Gdy problemem jest utrata dostępu, a nie niska przepustowość, osobny proces rozwiązywania problemów z uprawnieniami migracji NAS zapewnia odpowiednią ścieżkę diagnostyczną; nie jest to dowód na to, że xattr spowodowały spowolnienie.

Kiedy AppleDouble tworzy dodatkowe obiekty metadanych?

Pliki Mac mogą zawierać widelec danych, widelec zasobów, informacje Findera i inne metadane. Gdy miejsce docelowe nie może natywnie reprezentować pełnego obiektu, AppleDouble oferuje format dwuczęściowy. Definicja formatu AppleDouble oddziela normalny widelec danych od pliku nagłówkowego, który może przenosić widelec zasobów i atrybuty.

To wyjaśnia, dlaczego migracja może utworzyć towarzyszącą nazwę, taką jak plik z kropką i podkreśleniem, ale nie oznacza, że każdy plik Mac ją generuje. Dodatkowy obiekt jest istotny tylko wtedy, gdy metadane wymagają takiej reprezentacji, a ścieżka oprogramowania wybiera AppleDouble. Nowoczesne serwery Samba mogą również używać modułów metadanych Mac SMB oraz zapasowych xattr lub strumieni, więc dokładny wynik zależy od zachowania klienta, konfiguracji serwera i możliwości systemu plików.

Obiekty towarzyszące mogą zwiększyć pracę związaną z tworzeniem plików, katalogów, wyszukiwaniem, indeksowaniem i tworzeniem kopii zapasowych. Nie gwarantują one podwojenia całkowitej liczby plików ani spadku przepustowości o połowę. Problemy z połączeniem i dostępem między platformami to osobna kwestia; można skorzystać z kompatybilności SMB Windows i macOS po zrozumieniu mechanizmu metadanych.

Dlaczego każda powolna migracja nie jest problemem xattr?

Duże drzewa małych plików są wolne nawet, gdy nie ma opcjonalnych atrybutów. Tworzenie plików, blokowanie katalogów, sprawdzanie uprawnień, znaczniki czasu, zatwierdzenia dziennika, skanowanie antywirusowe, indeksowanie mediów, sumy kontrolne i weryfikacja na poziomie aplikacji mogą zmniejszyć liczbę plików przetwarzanych na sekundę. Zachowanie wyszukiwania HDD lub synchroniczne aktualizacje metadanych mogą zwiększać opóźnienia magazynu, ale żadne z nich nie dowodzi, że to xattr są za to odpowiedzialne.

Sieć może również wyglądać na bezczynność, podczas gdy klient i serwer czekają na operacje na poziomie obiektów. Ten wzorzec jest zgodny z pracą nad xattr, ale równie dobrze pasuje do zwykłego tworzenia plików, konfliktów katalogów lub synchronicznych zapisów. Wykorzystanie CPU i surowe megabajty na sekundę są więc niewystarczające same w sobie.

Najczystsze przypisanie to kontrolowane porównanie. Użyj tego samego zestawu plików, źródła, miejsca docelowego, protokołu, temperatury i stanu magazynu, a następnie porównaj przebieg zachowujący metadane z przebiegiem skupionym na zawartości, który pomija opcjonalne atrybuty. Różnica szacuje dodatkowy koszt zachowania w tym środowisku; nie staje się uniwersalnym benchmarkiem dla innego urządzenia NAS.

Co powinieneś zmierzyć przed zmianą polityki metadanych?

Zacznij od zestawu danych. Policz pliki i katalogi, sprawdź rozkład rozmiarów, zidentyfikuj, ile obiektów faktycznie posiada xattr i zanotuj, które przestrzenie nazw lub typy strumieni się pojawiają. Migracja zawierająca kilka plików z atrybutami ma inny profil ryzyka niż drzewo źródłowe, gdzie metadane aplikacji, ACL lub etykiety bezpieczeństwa są szeroko przypisane.

Mierz postęp zarówno w bajtach na sekundę, jak i plikach na sekundę. Rejestruj czas upływu, ostrzeżenia dotyczące metadanych, błędy docelowe, ślady protokołu, gdy są dostępne, obciążenie CPU, opóźnienia magazynu oraz pojawianie się plików towarzyszących. Pozwala to oddzielić limit przepustowości ładunku od limitu przetwarzania obiektów i pokazuje, czy spowolnienie zmienia się przy zmianie zachowania atrybutów.

Nie usuwaj metadanych tylko dlatego, że test staje się szybszy. Rsync w wersji upstream umożliwia zachowanie xattr za pomocą --xattrs lub -X, podczas gdy inne platformy i starsze wersje mogą używać innych opcji. Opcje rsync dotyczące xattr powinny być sprawdzone względem zainstalowanej wersji. Każdy zysk wydajności musi być rozważony w kontekście utraty ACL, kontekstu bezpieczeństwa, informacji Findera lub stanu aplikacji.

Najczęściej zadawane pytania

Czy każdy plik NAS ma atrybuty rozszerzone?

Nie. System plików może obsługiwać xattr, nie oznacza to jednak, że każdy plik ich używa. Niektóre pliki zawierają tagi użytkownika, ACL, etykiety bezpieczeństwa, informacje o zasobach lub metadane aplikacji, podczas gdy inne mają tylko zwykłą zawartość i podstawowe metadane. Sprawdzenie źródła jest bardziej wiarygodne niż zakładanie, że cały katalog ma atrybuty.

Dlaczego małe pliki są wolne, gdy nie mają xattr?

Każdy plik nadal wymaga utworzenia, aktualizacji katalogu, uprawnień, znaczników czasu, alokacji i operacji na uchwytach. Przy dużej liczbie obiektów te stałe koszty dominują nad transferem danych. Xattr mogą dodać kolejną warstwę, ale ich usunięcie nie wyeliminuje podstawowego obciążenia małych plików.

Czy pliki dot-underscore dowodzą, że AppleDouble spowodowało spowolnienie?

Nie. Wskazują one, że istnieją towarzyszące obiekty metadanych, co czyni hipotezę o pracy związanej z AppleDouble rozsądną. Nie kwantyfikują jednak czasu spędzonego na tych obiektach ani nie wykluczają indeksowania, tworzenia pliku bazowego, opóźnień w przechowywaniu i innych kosztów migracji.

Czy rsync domyślnie zachowuje atrybuty rozszerzone?

Nie w ogólnym zachowaniu upstream. Zachowanie xattr wymaga odpowiedniej opcji, a obsługiwane przestrzenie nazw nadal zależą od uprawnień i systemu plików docelowego. Ponieważ systemy operacyjne mogą mieć różne wersje rsync, sprawdź lokalną dokumentację przed interpretacją -X, -Elub zachowanie w trybie archiwum.

Czy przejście z SMB na NFS automatycznie rozwiąże problem?

Nie. Oba protokoły mają specyficzne dla implementacji zachowanie metadanych, a wsparcie xattr w NFSv4 jest opcjonalne. Wybór protokołu wiąże się także z uprawnieniami, kompatybilnością klienta, blokowaniem i dopasowaniem do obciążenia. Te szersze kompromisy należą do osobnego porównania SMB kontra NFS, a nie do wniosku o wydajności dotyczącego tylko xattr.

Ostateczne wnioski

Atrybuty rozszerzone mogą spowolnić migrację plików NAS, gdy zachowanie ich wymaga wystarczającej liczby odczytów, mapowań, zapisów lub obiektów towarzyszących na plik, aby stać się istotnym na dużą skalę. Potwierdź ten dodatkowy koszt za pomocą kontrolowanych pomiarów przed zmianą polityki metadanych i uwzględnij zwykłe obciążenie małych plików, zachowanie protokołu, indeksowanie, uprawnienia oraz opóźnienia w przechowywaniu w diagnozie.