5

I was wondering if there is any caching done with these utilities. I assume not, but not positive. Are there any typical similar utilities that do use caching to speed up results on subsequent runs?

Improve this question
5
  • I don't think that dd/df are doing the caching themselves but it rather some part of the kernel does that automatically Commented May 4, 2014 at 20:49
  • Maybe you ask the question in view of an other problem. When a program writes large logfiles and keep the filedescriptors open, deleting the files will not help making space free. The ugly program still has 'locked'the filespace. Commented May 4, 2014 at 21:24
  • @WalterA I am only asking out of curiosity, I dont have an issue with open file descriptors or unexpected output, but thank you. Commented May 4, 2014 at 22:12
  • Take a look at this question and my answer Commented Sep 17, 2019 at 0:10
  • @yuval Thanks! I have learned so much since I asked this ill-informed question (it's a little embarrassing to be reminded of this question, haha) Commented Sep 19, 2019 at 0:32

3 Answers 3

Reset to default
2

There is no need for caching in df as df does a single statfs() call (per filesystem). And obviously this call does read files on disk and sum up their sizes... The filesystems (e.g. the kernel) keep track of the free space.

du uses (without being aware of that) the page cache all applications use. In order to cache explicitly between runs there would have to be a "du daemon" anyway.

Improve this answer
3
  • 1
    du could have a cache without a daemon. All it has to do is store the directory sizes in a file somewhere, and then read back that file on next run. (not saying it does, just saying a daemon is not needed) Commented May 4, 2014 at 21:56
  • @Patrick But without something like inotify this would make caching a probability game. Commented May 4, 2014 at 21:59
  • Ah, thats why you meant daemon, so it could monitor real time. Yes, agree :-) Commented May 4, 2014 at 22:00
0

There is caching at some level (command or perhaps OS or FS-driver level - probably one of the latter two if you ask me), although forgive me for not knowing more details:

d@s7/mp3Ϡϡ time du -sh /mp3/ 27G /mp3/ du -sh /mp3/ 0.01s user 0.03s system 32% cpu 0.112 total d@s7/mp3Ϡϡ time du -sh /mp3/ 27G /mp3/ du -sh /mp3/ 0.00s user 0.01s system 82% cpu 0.015 total d@s7/mp3Ϡϡ time du -sh /mp3/ 27G /mp3/ du -sh /mp3/ 0.00s user 0.01s system 86% cpu 0.014 total d@s7/mp3Ϡϡ time du -sh /mp3/ 27G /mp3/ du -sh /mp3/ 0.01s user 0.01s system 78% cpu 0.020 total

Results obtained on Ubuntu 15.04 with ext4 filesystem, kernel version 3.19.0-15-generic.

Improve this answer
1
  • those margins are really tiny to meaningfully demonstrate caching performance. I would use a much larger directory Commented Apr 18, 2022 at 19:56
-2

confirm, it caches

see this:

$du -sh testUpload.txt 104M testUpload.txt $ dd if=/dev/zero of=testUpload.txt bs=1M count=50 50+0 records in 50+0 records out 52428800 bytes (52 MB, 50 MiB) copied, 0.0248501 s, 2.1 GB/s $ du -sh testUpload.txt 104M testUpload.txt <b> $ ls -al testUpload.txt -rw-rw-rw- 1 alfred alfred 52428800 Jul 4 11:50 testUpload.txt
Improve this answer
4
  • 1
    Cannot reproduce. What system is this? What filesystem is /tmp? Which du is it? Commented Jul 4, 2019 at 4:15
  • 1
    What is this supposed to be showing? Commented Jul 4, 2019 at 4:19
  • showing du is caching it, and it does not reflect the "new" size immediately. Commented Jul 4, 2019 at 9:50
  • du is showing you the amount used. You wrote zeros to it, so it's a sparse file and didn't add any addition usage. To see the apparent size, use du --apparent-size testUpload.txt Commented Mar 2, 2022 at 22:00

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.