Почему tar выводит содержимое файла, если выходной файл / dev / null?

У меня есть каталог с более чем 400 ГиБ данных в нем. Я хотел проверить, что все файлы могут быть прочитаны без ошибок, поэтому я подумал о том, как tarэто сделать /dev/null. Но вместо этого я вижу следующее поведение:

$ 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

Третья команда, приведенная выше, была принудительно остановлена Ctrl+ Cпосле достаточно долгого выполнения. Более того, в то время как первые две команды работали, индикатор активности устройства хранения .почти всегда был бездействующим. С третьей командой индикатор постоянно горит, что означает чрезвычайную занятость.

Таким образом, кажется, что, когда tarон может определить, что его выходной файл есть /dev/null, то есть, когда /dev/nullон непосредственно открывается, чтобы получить дескриптор файла, в который tarзаписывается, тело файла оказывается пропущенным. (При добавлении vопции tarвсе файлы в каталоге будут напечатаны tarкрасным цветом.)

Интересно, а почему это так? Это какая-то оптимизация? Если да, то зачем tarвообще делать такую ​​сомнительную оптимизацию для такого особого случая?

Я использую GNU tar 1.26 с glibc 2.27 в Linux 4.14.105 amd64.

Это является документированной оптимизация :

Когда архив создается для /dev/null, GNU tar пытается минимизировать операции ввода и вывода. Система резервного копирования Amanda, при использовании с GNU tar, имеет начальный этап определения размера, который использует эту функцию.

Это может случиться с различными программами, например, у меня такое поведение было когда-то при использовании cp file /dev/null; вместо оценки скорости чтения с моего диска команда вернулась через несколько миллисекунд.

Насколько я помню, это было в Solaris или AIX, но этот принцип применим ко всем видам Unix-Y систем.

В старые времена, когда программа копировала файл куда-то, она чередовалась между readвызовами, которые получают данные с диска (или с тем, на что ссылается дескриптор файла) в память (с гарантией, что все будет там, когда readвернется) и writeвызовами (которые берут кусок памяти и отправляют контент по назначению).

Тем не менее, есть как минимум два новых способа достижения того же:

• В Linux есть системные вызовы copy_file_range(вообще не переносимые на другие юниксы) и sendfile(несколько переносимые; изначально предназначенные для отправки файла в сеть, но теперь они могут использовать любой пункт назначения). Они предназначены для оптимизации переводов; если программа использует один из них, вполне возможно, что ядро ​​распознает цель /dev/nullи превращает системный вызов в неоперативный

• Программы могут использовать mmapдля получения содержимого файла вместо этого read, это в основном означает «убедиться, что данные есть, когда я пытаюсь получить доступ к этой части памяти» вместо «убедиться, что данные есть, когда системный вызов вернется». Таким образом, программа может получить mmapисходный файл, а затем вызвать writeэтот фрагмент отображенной памяти. Однако, поскольку запись /dev/nullне требует доступа к записанным данным, условие «убедитесь, что оно есть» никогда не запускается, в результате чего файл также не читается.

Не уверен , что если гну деготь использует любой, и которые из этих двух механизмов , когда он обнаруживает , что это пишет /dev/null, но они почему любая программа, когда используется для проверки чтения , скорости , должна работать с | cat > /dev/nullвместо > /dev/null- и почему | cat > /dev/nullдолжен следует избегать во всех остальных случаях.