How can I triage a discrepancy between my df and du output?
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
add a comment |
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
Also (helpful tips "buried" in the Question itself) - unix.stackexchange.com/questions/19425/…
– Jeff Schaller
Dec 20 '18 at 20:04
add a comment |
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
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
disk-usage
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
add a comment |
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
add a comment |
1 Answer
1
active
oldest
votes
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.
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
add a comment |
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.
add a comment |
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.
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.
edited Dec 20 '18 at 20:16
answered Dec 20 '18 at 19:59
slm♦
247k66511678
247k66511678
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
Also (helpful tips "buried" in the Question itself) - unix.stackexchange.com/questions/19425/…
– Jeff Schaller
Dec 20 '18 at 20:04