Mengapa tar muncul untuk melewatkan konten file ketika file output adalah / dev / null?

Saya memiliki direktori dengan lebih dari 400 GiB data di dalamnya. Aku ingin memeriksa bahwa semua file dapat dibaca tanpa kesalahan, sehingga cara sederhana saya pikir adalah untuk tarmenjadi /dev/null. Tetapi sebaliknya saya melihat perilaku berikut:

$ 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

Perintah ketiga di atas secara paksa dihentikan oleh Ctrl+ Csetelah berjalan cukup lama. Selain itu, sementara dua perintah pertama bekerja, indikator aktivitas perangkat penyimpanan yang berisi .hampir selalu tidak digunakan. Dengan perintah ketiga indikator terus menyala, yang berarti kesibukan ekstrem.

Jadi sepertinya, ketika tardapat mengetahui bahwa file outputnya /dev/null, yaitu ketika /dev/nulldibuka secara langsung untuk memiliki file handle yang tarditulis, file body muncul dilewati. (Menambahkan vopsi untuk tartidak mencetak semua file dalam direktori menjadi tar'merah.)

Jadi saya bertanya-tanya, mengapa demikian? Apakah ini semacam optimasi? Jika ya, lalu mengapa tarbahkan ingin melakukan optimasi yang meragukan untuk kasus khusus seperti itu?

Saya menggunakan GNU tar 1.26 dengan glibc 2.27 di Linux 4.14.105 amd64.

Ini adalah optimasi terdokumentasi :

Ketika arsip sedang dibuat /dev/null, tar GNU mencoba meminimalkan operasi input dan output. Sistem cadangan Amanda, ketika digunakan dengan GNU tar, memiliki pass ukuran awal yang menggunakan fitur ini.

Ini dapat terjadi dengan berbagai program, misalnya, saya memiliki perilaku itu sekali ketika hanya menggunakan cp file /dev/null; alih-alih mendapatkan perkiraan kecepatan baca disk saya, perintah kembali setelah beberapa milidetik.

Sejauh yang saya ingat, itu ada di Solaris atau AIX, tetapi prinsipnya berlaku untuk semua jenis sistem unix-y.

Di masa lalu, ketika sebuah program menyalin file ke suatu tempat, itu akan bergantian antara readpanggilan yang mendapatkan beberapa data dari disk (atau apa pun yang deskriptor file merujuk) ke memori (dengan jaminan semuanya ada di sana ketika readkembali) dan writepanggilan (Yang mengambil sebagian memori dan mengirim konten ke tujuan).

Namun, setidaknya ada dua cara baru untuk mencapai hal yang sama:

• Linux memiliki panggilan sistem copy_file_range(tidak portabel ke unix lain sama sekali) dan sendfile(agak portabel; awalnya dimaksudkan untuk mengirim file ke jaringan, tetapi dapat menggunakan tujuan apa pun sekarang). Mereka dimaksudkan untuk mengoptimalkan transfer; jika program menggunakan salah satu dari itu, mudah dibayangkan bahwa kernel mengenali targetnya/dev/null dan mengubah panggilan sistem menjadi no-op

• Program dapat digunakan mmapuntuk mendapatkan isi file alih-alih read, ini pada dasarnya berarti "pastikan data ada ketika saya mencoba mengakses potongan memori" daripada "pastikan data ada di sana ketika panggilan sistem kembali". Jadi suatu program dapat mmapsumber file, kemudian memanggil writepotongan memori yang dipetakan. Namun, karena tulisan /dev/nulltidak perlu mengakses data tertulis, kondisi "pastikan itu ada" tidak pernah dipicu, mengakibatkan file tidak dibaca juga.

Tidak yakin apakah gnu tar menggunakan, dan yang mana, dari dua mekanisme ini ketika mendeteksi itu sedang menulis /dev/null, tetapi mereka adalah alasan mengapa setiap program, ketika digunakan untuk memeriksa kecepatan baca , harus dijalankan dengan | cat > /dev/nullalih - alih > /dev/null- dan mengapa | cat > /dev/nullharus harus dihindari dalam semua kasus lain.