Dlaczego tar wydaje się pomijać zawartość pliku, gdy plik wyjściowy ma wartość / dev / null?

Mam katalog zawierający ponad 400 GiB danych. Chciałem sprawdzić, czy wszystkie pliki można odczytać bez błędów, więc pomyślałem o tartym w prosty sposób /dev/null. Zamiast tego widzę następujące zachowanie:

$ time tar cf /dev/null .

real    0m4.387s
user    0m3.462s
sys     0m0.185s
$ time tar cf - . > /dev/null

real    0m3.130s
user    0m3.091s
sys     0m0.035s
$ time tar cf - . | cat > /dev/null
^C

real    10m32.985s
user    0m1.942s
sys     0m33.764s

Trzecie polecenie powyżej zostało siłą zatrzymane przez Ctrl+ Cpo długim biegu. Ponadto, podczas gdy pierwsze dwa polecenia działały, wskaźnik aktywności zawierającego urządzenie pamięci masowej .był prawie zawsze bezczynny. Po trzecim poleceniu wskaźnik świeci się stale, co oznacza ekstremalne zajęcie.

Wygląda więc na to, że gdy tarjest w stanie dowiedzieć się, że jego plik wyjściowy jest /dev/null, tzn. Kiedy /dev/nulljest bezpośrednio otwierany, aby mieć uchwyt pliku, w którym tarzapisuje, ciało wydaje się pominięte. (Dodanie vopcji tarpowoduje wydrukowanie wszystkich plików w katalogu na tarczerwono).

Zastanawiam się więc, dlaczego tak jest? Czy to jakaś optymalizacja? Jeśli tak, to dlaczego miałby tarchcieć dokonać tak wątpliwej optymalizacji tak wyjątkowego przypadku?

Używam GNU tar 1.26 z glibc 2.27 na Linuksie 4.14.105 amd64.

Jest to udokumentowana optymalizacja :

Podczas tworzenia archiwum /dev/nullGNU tar próbuje zminimalizować operacje wejścia i wyjścia. System kopii zapasowej Amanda, gdy jest używany z GNU tar, ma początkową przepustowość, która korzysta z tej funkcji.

Może się to zdarzyć w przypadku różnych programów, na przykład miałem takie zachowanie raz, gdy tylko używałem cp file /dev/null; zamiast uzyskać szacunkową prędkość odczytu dysku, polecenie powróciło po kilku milisekundach.

O ile pamiętam, było to w systemie Solaris lub AIX, ale zasada ta dotyczy wszystkich rodzajów systemów unix-y.

W dawnych czasach, gdy program kopiował gdzieś plik, występował na przemian między readwywołaniami, które pobierają dane z dysku (lub dowolnego innego deskryptora pliku) do pamięci (z gwarancją, że wszystko jest tam, gdy readwraca) i writewywołań (które zajmują kawałek pamięci i wysyłają zawartość do miejsca docelowego).

Istnieją jednak co najmniej dwa nowsze sposoby osiągnięcia tego samego:

• Linux ma wywołania systemowe copy_file_range(w ogóle nieprzenośne dla innych uniksów) i sendfile(w pewnym stopniu przenośne; pierwotnie zamierzał wysłać plik do sieci, ale teraz może używać dowolnego miejsca docelowego). Mają na celu optymalizację transferów; jeśli program używa jednego z nich, łatwo można sobie wyobrazić, że jądro rozpoznaje cel /dev/nulli zamienia wywołanie systemowe w brak działania

• Programy mogą mmapzamiast readtego pobierać zawartość pliku , co w zasadzie oznacza „upewnij się, że dane tam są, gdy próbuję uzyskać dostęp do tej części pamięci” zamiast „upewnij się, że dane tam są, gdy wywołanie systemowe wróci”. Program może więc pobrać mmapplik źródłowy, a następnie wywołać writetę część zmapowanej pamięci. Ponieważ jednak zapis /dev/nullnie musi uzyskiwać dostępu do zapisanych danych, warunek „upewnij się, że tam jest” nie jest nigdy uruchamiany, co powoduje, że plik też nie jest odczytywany.

Nie jestem pewien, czy gnu tar używa któregoś z tych dwóch mechanizmów po wykryciu, że pisze /dev/null, ale są one powodem, dla którego dowolny program, używany do sprawdzania prędkości odczytu , powinien być uruchamiany | cat > /dev/nullzamiast > /dev/null- i dlaczego | cat > /dev/nullpowinien należy unikać we wszystkich innych przypadkach.