Why does tar appear to skip file contents when output file is /dev/null?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







2















I have a directory with over 400 GiB of data in it. I wanted to check that all the files can be read without errors, so a simple way I thought of was to tar it into /dev/null. But instead I see the following behavior:



$ 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


The third command above was forcibly stopped by Ctrl+C after having run for quite long already. Moreover, while the first two commands were working, activity indicator of the storage device containing . was nearly always idle. With the third command the indicator is constantly lit up, meaning extreme busyness.



So it seems that, when tar is able to find out that its output file is /dev/null, i.e. when /dev/null is directly opened to have the file handle which tar writes to, file body appears skipped. (Adding v option to tar does print all the files in the directory being tar'red.)



So I wonder, why is this so? Is it some kind of optimization? If yes, then why would tar even want to do such a dubious optimization for such a special case?



I'm using GNU tar 1.26 with glibc 2.27 on Linux 4.14.105 amd64.






tar null







share|improve this question





























    2















    I have a directory with over 400 GiB of data in it. I wanted to check that all the files can be read without errors, so a simple way I thought of was to tar it into /dev/null. But instead I see the following behavior:



    $ 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


    The third command above was forcibly stopped by Ctrl+C after having run for quite long already. Moreover, while the first two commands were working, activity indicator of the storage device containing . was nearly always idle. With the third command the indicator is constantly lit up, meaning extreme busyness.



    So it seems that, when tar is able to find out that its output file is /dev/null, i.e. when /dev/null is directly opened to have the file handle which tar writes to, file body appears skipped. (Adding v option to tar does print all the files in the directory being tar'red.)



    So I wonder, why is this so? Is it some kind of optimization? If yes, then why would tar even want to do such a dubious optimization for such a special case?



    I'm using GNU tar 1.26 with glibc 2.27 on Linux 4.14.105 amd64.






    tar null







    share|improve this question

























      2












      2








      2


      1






      I have a directory with over 400 GiB of data in it. I wanted to check that all the files can be read without errors, so a simple way I thought of was to tar it into /dev/null. But instead I see the following behavior:



      $ 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


      The third command above was forcibly stopped by Ctrl+C after having run for quite long already. Moreover, while the first two commands were working, activity indicator of the storage device containing . was nearly always idle. With the third command the indicator is constantly lit up, meaning extreme busyness.



      So it seems that, when tar is able to find out that its output file is /dev/null, i.e. when /dev/null is directly opened to have the file handle which tar writes to, file body appears skipped. (Adding v option to tar does print all the files in the directory being tar'red.)



      So I wonder, why is this so? Is it some kind of optimization? If yes, then why would tar even want to do such a dubious optimization for such a special case?



      I'm using GNU tar 1.26 with glibc 2.27 on Linux 4.14.105 amd64.






      tar null







      share|improve this question














      I have a directory with over 400 GiB of data in it. I wanted to check that all the files can be read without errors, so a simple way I thought of was to tar it into /dev/null. But instead I see the following behavior:



      $ 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


      The third command above was forcibly stopped by Ctrl+C after having run for quite long already. Moreover, while the first two commands were working, activity indicator of the storage device containing . was nearly always idle. With the third command the indicator is constantly lit up, meaning extreme busyness.



      So it seems that, when tar is able to find out that its output file is /dev/null, i.e. when /dev/null is directly opened to have the file handle which tar writes to, file body appears skipped. (Adding v option to tar does print all the files in the directory being tar'red.)



      So I wonder, why is this so? Is it some kind of optimization? If yes, then why would tar even want to do such a dubious optimization for such a special case?



      I'm using GNU tar 1.26 with glibc 2.27 on Linux 4.14.105 amd64.






      tar null




      tar null






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked 32 mins ago









      RuslanRuslan

      1,3961427




      1,3961427






















          1 Answer
          1






          active

          oldest

          votes


















          4














          It is a documented optimization:




          When the archive is being created to /dev/null, GNU tar tries to
          minimize input and output operations. The Amanda backup system, when
          used with GNU tar, has an initial sizing pass which uses this feature.







          share|improve this answer
























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "106"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f512362%2fwhy-does-tar-appear-to-skip-file-contents-when-output-file-is-dev-null%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            4














            It is a documented optimization:




            When the archive is being created to /dev/null, GNU tar tries to
            minimize input and output operations. The Amanda backup system, when
            used with GNU tar, has an initial sizing pass which uses this feature.







            share|improve this answer




























              4














              It is a documented optimization:




              When the archive is being created to /dev/null, GNU tar tries to
              minimize input and output operations. The Amanda backup system, when
              used with GNU tar, has an initial sizing pass which uses this feature.







              share|improve this answer


























                4












                4








                4







                It is a documented optimization:




                When the archive is being created to /dev/null, GNU tar tries to
                minimize input and output operations. The Amanda backup system, when
                used with GNU tar, has an initial sizing pass which uses this feature.







                share|improve this answer













                It is a documented optimization:




                When the archive is being created to /dev/null, GNU tar tries to
                minimize input and output operations. The Amanda backup system, when
                used with GNU tar, has an initial sizing pass which uses this feature.








                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered 14 mins ago









                murumuru

                37.7k589165




                37.7k589165






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid …



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f512362%2fwhy-does-tar-appear-to-skip-file-contents-when-output-file-is-dev-null%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    -

                    Popular posts from this blog

                    How to label and detect the document text images

                    Image
                    1 $begingroup$ This is what I mean as document text image: I want to label the texts in image as separate blocks and my model should detect these labels as classes. NOTE: This is how the end result should be like: The labels like Block 1, Block 2, Block 3,.. should be Logo, Title, Date,.. Others, etc. Work done: First approach : I tried to implement this method via Object Detection, it didn't work. It didn't even detect any text. Second approach : Then I tried it using PixelLink. As this model is build for scene text detection, it detected each and every text in the image. But this method can detect multiple lines of text if the threshold values are increased. But I have no idea how do I add labels to the text blocks. PIXEL_CLS_WEIGHT_all_ones = 'PIXEL_CLS_WEIGHT_all_ones' PIXEL_C...
                    Read more

                    Vallis Paradisi

                    Image
                    Coordinata: .mw-parser-output .geo-default,.mw-parser-output .geo-dms,.mw-parser-output .geo-dec{display:inline}.mw-parser-output .geo-nondefault,.mw-parser-output .geo-multi-punct{display:none}.mw-parser-output .longitude,.mw-parser-output .latitude{white-space:nowrap} 33°03′S 71°37′W  /  33.05°S 71.617°W  / -33.05; -71.617 Vallis Paradisi Res apud Vicidata repertae: Civitas : Chilia Numerus incolarum : 296 655 Zona horaria : UTC-4 Situs interretialis Nomen officiale : Valparaíso Gubernium Consilium : municipal council of Valparaíso Geographia Superficies : 401 600 000 Metrum quadratum Coniunctiones urbium Urbes gemellae : Ovetum , Badalona , Santa Fe , Ora longa , Sciamhaevum , Quantunia , Callao , Bat Yam , Melaka , Novorossiysk , Busan , Corduba , Odessa , Rosario , Malacca , Barcino , Soteropolis , Franciscopolis (California) , Guanajuato, Silao Tabula aut despectus Despectus in portum sinumque et urbem Vallis Paradisi Vallis Para...
                    Read more

                    Tabula Rosettana

                    Image
                    Tabula multilinguis Rosettana in Museo Britannico ostenditur. Tabula Rosettana, [1] etiam titulo OGIS 90 agnita, est stela decreto de rebus sacris in Aegypto anno 196 a.C.n. lato inscripta. Tabula iuxta Rosettam Aegypti, urbem in delta Nili et ad oram maris Mediterranei iacentem, anno 1799 a milite Francico reperta est. Inventio stelae, linguis duabus scripturisque tribus inscriptae, eruditis Instituti Aegypti statim nuntiata est; ibi enim iussu imperatoris Napoleonis eruditi omnium scientiarum (sub aegide Commissionis Scientiarum et Artium) properaverant cum expeditione Francica. Qua a Britannis mox debellata, tabula Rosettana Londinium missa hodie apud Museum Britannicum iacet. Textus Graecus cito lectus interpretationi textuum Aegyptiorum (in formis hieroglyphica et demotica expressorum) gradatim adiuvit. Denique textum plene interpretatus est Ioannes Franciscus Champollion. Ab opere eruditorum cumulativo coepit hodiernus scripturae hieroglyphicae linguaeque Aegyptiae a...
                    Read more