Jak śledzić zdalny transfer pliku, który kończy się niepowodzeniem przy tym samym rozmiarze pliku

Transfer, który wielokrotnie kończy się niepowodzeniem przy tej samej liczbie bajtów, zwykle napotyka na deterministyczny limit lub etap po transferze, a nie na losową utratę pakietów.

W przypadku zdalnego NAS lub samodzielnie hostowanej usługi plików, widoczny punkt awarii może wynikać z systemu plików docelowego, dostępnej przestrzeni lub egzekwowania limitu kwoty, ograniczenia przesyłania w aplikacji, reverse proxy, 32-bitowego licznika klienta, stałego czasu trwania połączenia lub przetwarzania sumy kontrolnej po dotarciu ładunku. Najszybsza diagnoza polega na zapisaniu dokładnego przesunięcia bajtu i upływającego czasu, a następnie zmianie rozmiaru pliku, prędkości transferu, protokołu i miejsca docelowego, zmieniając jedną zmienną na raz.

Zapisz Dokładne Przesunięcie Bajtu i Fazę Awarii

Wykonaj ten sam transfer dwukrotnie i zanotuj rozmiar źródła, przesłane bajty, procent, upływający czas, błąd klienta, błąd serwera oraz czy pozostał plik częściowy. Rozróżnij awarię podczas transferu ładunku od awarii podczas zmiany nazwy, sumy kontrolnej, zatwierdzenia, indeksowania lub ostatecznego potwierdzenia API.

Przypadek wsparcia WinSCP wielokrotnie kończył się niepowodzeniem przy 4 GB, aż użytkownik zidentyfikował limit rozmiaru pliku FAT32. Dokładna granica bajtowa ujawniła ograniczenie magazynowania, a nie problem z trasowaniem SFTP lub SCP.

Jeśli liczba bajtów jest identyczna w niewielkim marginesie, priorytetowo traktuj stałe limity i granice całkowite. Jeśli upływający czas jest identyczny, ale liczba bajtów zmienia się wraz z prędkością transferu, priorytetowo traktuj limity czasu połączenia, proxy, bezczynności lub uwierzytelniania.

Zmień Prędkość Transferu, aby Oddzielić Rozmiar od Czasu

Prześlij ten sam plik raz normalną ścieżką zdalną, a raz przez celowo wolniejszą lub szybszą ścieżkę. Zanotuj, czy awaria następuje po tej samej liczbie bajtów, czy po tym samym czasie trwania.

Dyskusja na temat API Dropbox wykazała, że pliki, które wydawały się kończyć niepowodzeniem powyżej 4 GB, mogły w rzeczywistości odzwierciedlać limit czasu żądania HTTP i zasugerowała częściowe pobieranie oparte na zakresie, aby uniknąć jednego długiego żądania.

Gdy liczba bajtów się zmienia, ale upływający czas pozostaje stabilny, sprawdź czas życia sesji tunelu, limit czasu odczytu proxy, wygasające tokeny i wykrywanie bezczynności. Gdy awaria pozostaje przy jednej dokładnej wartości bajtów pomimo dużej zmiany prędkości, kontynuuj badanie limitów systemu plików, kwoty, klienta i aplikacji.

Przetestuj Kilka Plików Wokół Podejrzewanej Granicy

Utwórz lub wybierz pliki tuż poniżej, dokładnie na i tuż powyżej rozmiaru powodującego awarię. Przetestuj także inny plik o tym samym rozmiarze, aby zawartość, nazwa pliku, kompresja i metadane nie stały się ukrytymi zmiennymi.

Raport na forum FlashFXP opisywał transfer FTP, który zatrzymywał się dokładnie na 4,00 GB. Granice będące potęgami dwójki, takie jak 2 GB, 4 GB czy 8 GB, często wskazują na limit licznika, systemu plików lub aplikacji.

Jeśli każdy plik powyżej progu kończy się niepowodzeniem, sprawdź twarde limity. Jeśli niepowodzenie dotyczy tylko jednego pliku, porównaj długość ścieżki, znaki w nazwie pliku, obszary rzadkie, uprawnienia, błędy odczytu źródła oraz czy przetwarzanie po stronie serwera traktuje ten typ pliku inaczej.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Sprawdź System Plików Docelowego, Kwotę i Przestrzeń Tymczasową

Ustal system plików przechowujący plik końcowy oraz system plików przechowujący tymczasowe przesyłanie. Sprawdź maksymalny rozmiar pliku, wolne bajty, wolne inody, kwotę użytkownika, kwotę zestawu danych, pojemność wolumenu kontenera oraz wszelkie partycje stagingowe.

Zdalna usługa może zaakceptować cały strumień do lokalizacji tymczasowej i zakończyć się niepowodzeniem dopiero podczas przenoszenia lub zatwierdzania pliku. Powoduje to błąd klienta blisko 100 procent, mimo że ścieżka sieciowa dostarczyła prawie wszystkie bajty.

Prześlij ten sam plik na inny udział lub zestaw danych na tym samym NAS. Jeśli limit podąża za miejscem docelowym, napraw jego system plików, kwotę lub przestrzeń stagingową; jeśli podąża za klientem lub protokołem w różnych miejscach docelowych, kontynuuj poza warstwą magazynowania.

Omijaj Aplikację, Proxy lub Tunel Warstwa po Warstwie

Porównaj normalny zdalny przepływ pracy z bezpośrednim testem protokołu: SFTP zamiast przesyłania przez sieć web, bezpośredni dostęp VPN zamiast publicznego reverse proxy lub transfer lokalny LAN zamiast zdalnego tunelu. Zachowaj to samo źródło i miejsce docelowe przechowywania.

Użytkownik rclone odkrył, że duże przesyłania wielokrotnie się restartowały po długiej przerwie, aż do zmiany limitu czasu, podczas gdy serwer wydawał się wykonywać pracę sumy kontrolnej po przesłaniu. Ilustruje to, dlaczego awaria na końcu tego samego pliku nie zawsze oznacza limit liczby bajtów.

Jeśli bezpośrednie SFTP się powiodło, a ścieżka webowa zawiodła, sprawdź limity przesyłania aplikacji i proxy. Jeśli transfer lokalny się powiódł, ale każdy zdalny protokół kończy się niepowodzeniem po tym samym czasie, sprawdź tunel, ścieżkę ISP, czas życia sesji i urządzenia pośredniczące.

Zweryfikuj Naprawę Testami Wznowienia i Sumy Kontrolnej

Po skorygowaniu podejrzewanego limitu powtórz testy plików poniżej i powyżej starej granicy. Sprawdź, czy protokół wznawia celowo przerwany transfer oraz czy końcowa suma kontrolna pliku zgadza się ze źródłem.

Przepływ pracy ZimaSpace dla etapowania dużych transferów NAS zapewnia bezpieczniejszy sposób na ponowne testowanie bez rozpoczynania od zera wieloterabajtowego zadania.

Diagnoza jest kompletna tylko wtedy, gdy stara granica jest wielokrotnie przekraczana, serwer zatwierdza plik, suma kontrolna się zgadza, a logi identyfikują poprawioną warstwę. Nie akceptuj automatycznych ponowień, które ukrywają deterministyczną awarię i cicho marnują przepustowość.