How can I triage a discrepancy between my df and du output?












1














NOTE: I'm fully aware of these other questions on this site:




  • Why are there so many different ways to measure disk usage?

  • du on ramdisk displays 3GB less than df


My issue shows up as follows:



$ du -sh / --exclude=/proc
4.0G /


vs.



$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_os-lv_root 18G 16.0G 1.9G 90% /
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 39M 3.8G 1% /dev/shm
tmpfs 3.9G 17M 3.9G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/vda1 497M 215M 283M 44% /boot
tmpfs 783M 0 783M 0% /run/user/937000511
tmpfs 783M 0 783M 0% /run/user/937000593


How can I triage this issue to determine what's causing this discrepancy?










share|improve this question
























  • Also (helpful tips "buried" in the Question itself) - unix.stackexchange.com/questions/19425/…
    – Jeff Schaller
    Dec 20 '18 at 20:04
















1














NOTE: I'm fully aware of these other questions on this site:




  • Why are there so many different ways to measure disk usage?

  • du on ramdisk displays 3GB less than df


My issue shows up as follows:



$ du -sh / --exclude=/proc
4.0G /


vs.



$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_os-lv_root 18G 16.0G 1.9G 90% /
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 39M 3.8G 1% /dev/shm
tmpfs 3.9G 17M 3.9G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/vda1 497M 215M 283M 44% /boot
tmpfs 783M 0 783M 0% /run/user/937000511
tmpfs 783M 0 783M 0% /run/user/937000593


How can I triage this issue to determine what's causing this discrepancy?










share|improve this question
























  • Also (helpful tips "buried" in the Question itself) - unix.stackexchange.com/questions/19425/…
    – Jeff Schaller
    Dec 20 '18 at 20:04














1












1








1







NOTE: I'm fully aware of these other questions on this site:




  • Why are there so many different ways to measure disk usage?

  • du on ramdisk displays 3GB less than df


My issue shows up as follows:



$ du -sh / --exclude=/proc
4.0G /


vs.



$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_os-lv_root 18G 16.0G 1.9G 90% /
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 39M 3.8G 1% /dev/shm
tmpfs 3.9G 17M 3.9G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/vda1 497M 215M 283M 44% /boot
tmpfs 783M 0 783M 0% /run/user/937000511
tmpfs 783M 0 783M 0% /run/user/937000593


How can I triage this issue to determine what's causing this discrepancy?










share|improve this question















NOTE: I'm fully aware of these other questions on this site:




  • Why are there so many different ways to measure disk usage?

  • du on ramdisk displays 3GB less than df


My issue shows up as follows:



$ du -sh / --exclude=/proc
4.0G /


vs.



$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_os-lv_root 18G 16.0G 1.9G 90% /
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 39M 3.8G 1% /dev/shm
tmpfs 3.9G 17M 3.9G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/vda1 497M 215M 283M 44% /boot
tmpfs 783M 0 783M 0% /run/user/937000511
tmpfs 783M 0 783M 0% /run/user/937000593


How can I triage this issue to determine what's causing this discrepancy?







disk-usage






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 20 '18 at 20:10

























asked Dec 20 '18 at 19:59









slm

247k66511678




247k66511678












  • Also (helpful tips "buried" in the Question itself) - unix.stackexchange.com/questions/19425/…
    – Jeff Schaller
    Dec 20 '18 at 20:04


















  • Also (helpful tips "buried" in the Question itself) - unix.stackexchange.com/questions/19425/…
    – Jeff Schaller
    Dec 20 '18 at 20:04
















Also (helpful tips "buried" in the Question itself) - unix.stackexchange.com/questions/19425/…
– Jeff Schaller
Dec 20 '18 at 20:04




Also (helpful tips "buried" in the Question itself) - unix.stackexchange.com/questions/19425/…
– Jeff Schaller
Dec 20 '18 at 20:04










1 Answer
1






active

oldest

votes


















2














In this particular case the problem was a daemon running which had its files rotated via logrotate but the service wasn't sent a kill -HUP to trigger it to start logging to a new file. This resulted in a 12G log file continuing to show up as though it were consuming space on the HDD which was visible via df but not du, given how both of these CLI tools work.



lsof



Using lsof and looking for the log file showed the issue:



$ lsof | grep -E 'COMMAND|/var/log/maxscale'
COMMAND PID TID USER FD TYPE DEVICE SIZE/OFF NODE NAME
maxscale 5976 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
maxscale 5976 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
maxscale 5976 5977 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
maxscale 5976 5977 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
maxscale 5976 5978 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
maxscale 5976 5978 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
maxscale 5976 5979 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
maxscale 5976 5979 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
maxscale 5976 5980 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
maxscale 5976 5980 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
MHD-singl 5976 5981 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
MHD-singl 5976 5981 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
bash 12629 root cwd DIR 253,1 4096 82757 /var/log/maxscale


The lsof output even shows the size in question and that it was in fact deleted:




maxscale 5976 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)




Stopping the daemon released/closed the file descriptor freeing the space:



$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_os-lv_root 18G 4.0G 14G 23% /
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 39M 3.8G 1% /dev/shm
tmpfs 3.9G 17M 3.9G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/vda1 497M 215M 283M 44% /boot
tmpfs 783M 0 783M 0% /run/user/937000511
tmpfs 783M 0 783M 0% /run/user/937000593


Now df and du are in agreement.






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%2f490195%2fhow-can-i-triage-a-discrepancy-between-my-df-and-du-output%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









    2














    In this particular case the problem was a daemon running which had its files rotated via logrotate but the service wasn't sent a kill -HUP to trigger it to start logging to a new file. This resulted in a 12G log file continuing to show up as though it were consuming space on the HDD which was visible via df but not du, given how both of these CLI tools work.



    lsof



    Using lsof and looking for the log file showed the issue:



    $ lsof | grep -E 'COMMAND|/var/log/maxscale'
    COMMAND PID TID USER FD TYPE DEVICE SIZE/OFF NODE NAME
    maxscale 5976 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
    maxscale 5976 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
    maxscale 5976 5977 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
    maxscale 5976 5977 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
    maxscale 5976 5978 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
    maxscale 5976 5978 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
    maxscale 5976 5979 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
    maxscale 5976 5979 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
    maxscale 5976 5980 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
    maxscale 5976 5980 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
    MHD-singl 5976 5981 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
    MHD-singl 5976 5981 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
    bash 12629 root cwd DIR 253,1 4096 82757 /var/log/maxscale


    The lsof output even shows the size in question and that it was in fact deleted:




    maxscale 5976 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)




    Stopping the daemon released/closed the file descriptor freeing the space:



    $ df -h
    Filesystem Size Used Avail Use% Mounted on
    /dev/mapper/vg_os-lv_root 18G 4.0G 14G 23% /
    devtmpfs 3.9G 0 3.9G 0% /dev
    tmpfs 3.9G 39M 3.8G 1% /dev/shm
    tmpfs 3.9G 17M 3.9G 1% /run
    tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
    /dev/vda1 497M 215M 283M 44% /boot
    tmpfs 783M 0 783M 0% /run/user/937000511
    tmpfs 783M 0 783M 0% /run/user/937000593


    Now df and du are in agreement.






    share|improve this answer




























      2














      In this particular case the problem was a daemon running which had its files rotated via logrotate but the service wasn't sent a kill -HUP to trigger it to start logging to a new file. This resulted in a 12G log file continuing to show up as though it were consuming space on the HDD which was visible via df but not du, given how both of these CLI tools work.



      lsof



      Using lsof and looking for the log file showed the issue:



      $ lsof | grep -E 'COMMAND|/var/log/maxscale'
      COMMAND PID TID USER FD TYPE DEVICE SIZE/OFF NODE NAME
      maxscale 5976 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
      maxscale 5976 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
      maxscale 5976 5977 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
      maxscale 5976 5977 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
      maxscale 5976 5978 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
      maxscale 5976 5978 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
      maxscale 5976 5979 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
      maxscale 5976 5979 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
      maxscale 5976 5980 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
      maxscale 5976 5980 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
      MHD-singl 5976 5981 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
      MHD-singl 5976 5981 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
      bash 12629 root cwd DIR 253,1 4096 82757 /var/log/maxscale


      The lsof output even shows the size in question and that it was in fact deleted:




      maxscale 5976 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)




      Stopping the daemon released/closed the file descriptor freeing the space:



      $ df -h
      Filesystem Size Used Avail Use% Mounted on
      /dev/mapper/vg_os-lv_root 18G 4.0G 14G 23% /
      devtmpfs 3.9G 0 3.9G 0% /dev
      tmpfs 3.9G 39M 3.8G 1% /dev/shm
      tmpfs 3.9G 17M 3.9G 1% /run
      tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
      /dev/vda1 497M 215M 283M 44% /boot
      tmpfs 783M 0 783M 0% /run/user/937000511
      tmpfs 783M 0 783M 0% /run/user/937000593


      Now df and du are in agreement.






      share|improve this answer


























        2












        2








        2






        In this particular case the problem was a daemon running which had its files rotated via logrotate but the service wasn't sent a kill -HUP to trigger it to start logging to a new file. This resulted in a 12G log file continuing to show up as though it were consuming space on the HDD which was visible via df but not du, given how both of these CLI tools work.



        lsof



        Using lsof and looking for the log file showed the issue:



        $ lsof | grep -E 'COMMAND|/var/log/maxscale'
        COMMAND PID TID USER FD TYPE DEVICE SIZE/OFF NODE NAME
        maxscale 5976 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
        maxscale 5976 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
        maxscale 5976 5977 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
        maxscale 5976 5977 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
        maxscale 5976 5978 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
        maxscale 5976 5978 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
        maxscale 5976 5979 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
        maxscale 5976 5979 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
        maxscale 5976 5980 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
        maxscale 5976 5980 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
        MHD-singl 5976 5981 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
        MHD-singl 5976 5981 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
        bash 12629 root cwd DIR 253,1 4096 82757 /var/log/maxscale


        The lsof output even shows the size in question and that it was in fact deleted:




        maxscale 5976 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)




        Stopping the daemon released/closed the file descriptor freeing the space:



        $ df -h
        Filesystem Size Used Avail Use% Mounted on
        /dev/mapper/vg_os-lv_root 18G 4.0G 14G 23% /
        devtmpfs 3.9G 0 3.9G 0% /dev
        tmpfs 3.9G 39M 3.8G 1% /dev/shm
        tmpfs 3.9G 17M 3.9G 1% /run
        tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
        /dev/vda1 497M 215M 283M 44% /boot
        tmpfs 783M 0 783M 0% /run/user/937000511
        tmpfs 783M 0 783M 0% /run/user/937000593


        Now df and du are in agreement.






        share|improve this answer














        In this particular case the problem was a daemon running which had its files rotated via logrotate but the service wasn't sent a kill -HUP to trigger it to start logging to a new file. This resulted in a 12G log file continuing to show up as though it were consuming space on the HDD which was visible via df but not du, given how both of these CLI tools work.



        lsof



        Using lsof and looking for the log file showed the issue:



        $ lsof | grep -E 'COMMAND|/var/log/maxscale'
        COMMAND PID TID USER FD TYPE DEVICE SIZE/OFF NODE NAME
        maxscale 5976 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
        maxscale 5976 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
        maxscale 5976 5977 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
        maxscale 5976 5977 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
        maxscale 5976 5978 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
        maxscale 5976 5978 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
        maxscale 5976 5979 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
        maxscale 5976 5979 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
        maxscale 5976 5980 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
        maxscale 5976 5980 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
        MHD-singl 5976 5981 maxscale cwd DIR 253,1 4096 82757 /var/log/maxscale
        MHD-singl 5976 5981 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)
        bash 12629 root cwd DIR 253,1 4096 82757 /var/log/maxscale


        The lsof output even shows the size in question and that it was in fact deleted:




        maxscale 5976 maxscale 4w REG 253,1 12506246848 82752 /var/log/maxscale/maxscale.log (deleted)




        Stopping the daemon released/closed the file descriptor freeing the space:



        $ df -h
        Filesystem Size Used Avail Use% Mounted on
        /dev/mapper/vg_os-lv_root 18G 4.0G 14G 23% /
        devtmpfs 3.9G 0 3.9G 0% /dev
        tmpfs 3.9G 39M 3.8G 1% /dev/shm
        tmpfs 3.9G 17M 3.9G 1% /run
        tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
        /dev/vda1 497M 215M 283M 44% /boot
        tmpfs 783M 0 783M 0% /run/user/937000511
        tmpfs 783M 0 783M 0% /run/user/937000593


        Now df and du are in agreement.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Dec 20 '18 at 20:16

























        answered Dec 20 '18 at 19:59









        slm

        247k66511678




        247k66511678






























            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.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • 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%2f490195%2fhow-can-i-triage-a-discrepancy-between-my-df-and-du-output%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

            Morgemoulin

            Scott Moir

            Souastre