Otdfbt

I wrote a small script to print the memory usage during a large sequential write of a file.

#!/bin/bash
rm result
echo 3 > /proc/sys/vm/drop_caches
sync;
echo start
nohup time dd if=/dev/zero of=mem bs=1M count=2000 & 
for i in 1..200
do
 sleep 0.2
 cat /proc/meminfo | grep Dirty >> result
 cat /proc/meminfo | grep Dirty
done
cat nohup.out
cat result

I should see the increase of the "Dirty" size from the beginning of the run. But when I ran the script, I often see a big delay (up to several seconds), during which the "Dirty" size does not increase, which possibly means the start of "dd" program is delayed. A sample problematic output is:

Dirty: 20 kB
Dirty: 20 kB
Dirty: 20 kB
Dirty: 20 kB
Dirty: 20 kB
Dirty: 24 kB
Dirty: 24 kB
Dirty: 24 kB
Dirty: 24 kB
Dirty: 28 kB
Dirty: 28 kB
Dirty: 28 kB
Dirty: 28 kB
Dirty: 28 kB
Dirty: 16528 kB
Dirty: 140608 kB
Dirty: 277228 kB
Dirty: 311768 kB
Dirty: 434308 kB
Dirty: 563352 kB
Dirty: 690952 kB
...

The length of the delay is uncertain, sometimes there's no delay at all. And in contrast, when I ran

time dd if=/dev/zero of=mem bs=1M count=2000

with some real time meminfo viewer, such as:

#!/bin/bash
clear
while true
do
 sleep 0.2
 tput home
 cat /proc/meminfo
done

I always see the "Dirty" size increases immediately. Is there something wrong with my script? I also doubt about how the "write" operation is executed by the OS, because I also tested the file read and detected the "Cached" field in /proc/meminfo, and it seems to have no delay at all.

Thanks,

nohup time dd if=/dev/zero of=mem bs=1M count=2000 & 

do you have a "time" binary on your system? otherwise nohup wouldn't know how to run a bash internal by itself and it will fail

You can determine what is taking up the additional time by either invoking the script with

/bin/bash -x /path/to/script

and watching the output. This will print each line of code of the script as it executes. Alternatively you could preface each command with the time command and what is taking the additional time will become readily apparent.

Can you please reboot the system and make sure not too much write happening post restart at least from application side, now try to execute your dd command, reason is if you want to test write operations system should be clean and stable.
Your delay will depend on what kind of fs parameters and type of filesystem you are going to use.
Hope this will help.