cp filename /dev/null spins root disk

[Roland Rebstock_1]

Why in HPUX 11/10 etc.. when I time cp filename /dev/null and run sar -d 1 10 I see the root drive spin up to 100% and it take 15 sec's but in SOLARIS when I do the same thing their is no IO from sar and my prompt comes back immediately?

[Sandip Ghosh]

Because the /dev directory is in the root disk.

Sandip

[Sridhar Bhaskarla]

Hi Roland,

How big is the file?.

If it is large and on the root disk, sure it will cause root disk to spin as it has to read from it.

-Sri

[Sridhar Bhaskarla]

And make sure /dev/null is a device file.

-Sri

[Jeff Schussele]

Hi Roland,

Depending on the location of "filename" you may be reading it from the root disk.
But regardless the system is actually writing it to /dev/null - on the root disk - which obediently sends it to the "ether" never to be seen again. You'd see the same thing if you copied it to a device file such as /dev/console.
Remember HP-UX is a "file-based" OS & treats EVERYTHING as a file & this includes devices such as null.

Sun is probably interpreting the command differently & noting that copying to /dev/null is "pointless" and doing nothing.

Rgds,
Jeff

[Roland Rebstock_1]

here is a update, It doesnt matter where the file is located, it could be on the root disk or a seperate PV/LV sitting on a EMC Frame. HP still utilizes the root disk when cp'ing to /dev/null and Solaris just gets rid of it without doing any write/read. The problem here is a customer of mine is attempting to benchmark their system, a Blown N Class against a Blown 4500 SUN Solaris box and Solaris just take the file against time and says 0.0 with a sar -d on the disks of the LV report 0.0 for w,r,rw. I have used IOzone to prove its not a problem but they seem to only care about cp /dev/null even when their app does not even do this.

[A. Clay Stephenson]

I thought this was insane but I tested it on my sandbox just to be sure. I copied many files to /dev/null and there was no root disk activity.

As has been mentioned, I suspect that your /dev/null has somehow become a regular file rather than a device node. Do an ls -l /dev/null. It should be a character special device with major device number 3, minor 2.

[Jeff Schussele]

Roland,

My grandfather, may he rest in peace, always told me
"You can't fix stupid."

My question in response to them would be Benchmark exactly what?


Rgds,
Jeff

[Roland Rebstock_1]

I checked /dev and the device is crw-rw-rw- 1 bin bin 3 0x000002 Apr25 14:45 /dev/null.

In response to the benchmark what? question, the client states that they are measuring between solaris and hpux a cp filename to /dev/null and in Solaris the disks do not spin up in looking at a sar -d and the command executes with time immediately with a prompt # that followes with 0.0s. In HPUX and I checked many HPUX servers in our environment, when I do it here no matter if it is a root disk or a disk sitting on a Frame, the root disk spins up to 100% in sar until the time cp filename /dev/null completes which is anywhere in the 45s range on a 1gb file. In Solaris, I have tested this with a 6gb file and yet no disk activity and the command executes with time at 0.0. I just want to know why their are differences in OS's. I agree this is not a valid benchmark test and I think the client is NUTS but I still for my own sanity like to answer this question and throw it in their face.

[Tim Clemens]

Roland:
I don't get the same response that you are describing. The disk the spins up to 100% is the disk which contains the source file. Of course, this is all 100% read IO. There is little if any IO to the root disk. Even if I use the time command, there is still no root disk IO. It does however, take time to read the file.
I've tried it on 11.0 and 11i and used glance to watch the disk IO (the 'u' screen). Something else it going on here. Have you another machine to time it on?

[Mark Fenton]

Copying a 100MB file to /dev/null on my system produced not a flicker of activity in terms of disk usage, and finished nearly instantly.
# time cp /stand/vmunix.prev /dev/null
real 0.8
user 0.0
sys 0.1

(N4000 w/2 CPU @ 360MHz, 1GB RAM, normal disk systems, HP-UX 11.0)

Copying a 600MB file from external RAID to /dev/null produced:
# time cp bigfile /dev/null
real 14.2
user 0.0
sys 2.6

Hope you can solve this

Mark

[Roland Rebstock_1]

exactly what I am talking about. You see on Solaris it always comes back with a prompt immediately and no time to speak of. 0.0 or 0.1. Its like Solaris has a different take on this like it knows that since your copying to /dev/null why even do it? I have a case open on this and the tech thought it might be due to asyn to sync writes. HP-UX uses synchronous disk I/O by defaut and Solaris uses asynchronous disk I/O by default. But I change this on the HPUX kernel but it did not test with different results. They also have came back that its the dbc_max_pct setting but I have up'd this on a test box but it did not yeild different results. They are still checking.