Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.sys.hp Subject: Re: Disk performance HP-UX 6.5 Message-ID: <2771@auspex.auspex.com> Date: 20 Dec 89 03:19:17 GMT References: <2437@ifi.uio.no> <17330009@hpfcdj.HP.COM> Organization: Auspex Systems, Santa Clara Lines: 31 >Actaully, what's happening here isn't what you think either. Nor is it what you think.... >SunOS 4 does ALL io (save raw devices!) via memory mapping of >files (including block devices as well I believe), and does not >read data in, if that's written to /dev/null immediately >thereafter (this because of copy-on-write). SunOS does, in fact, do UFS and NFS I/O by something that basically amounts to memory mapping. What a "read" of a UFS or NFS file, or, I think, a block special file amounts to is "map the region being read into the kernel's address space, and then copy from that mapped region into the user's buffer". The kernel obviously has no idea that the data in question is going to be written to "/dev/null", so it copies it anyway, which means it has to fault the data in from the file if it's not already in memory. (Yes, I've read the code; that's how it works.) >Try doing 'time cp /vmunix /dev/null' under SunOS 4, SunOS 3, and >HP-UX, and you will see; especially if run under the C shell, >that gives you a count of IO operations. That's different from "dd". "cp" doesn't do "read"s from "/vmunix", it "mmap"s "/vmunix" into *its* address space and then writes that mapped region to "/dev/null". *That* write, obviously, never touches the data, so it doesn't have to be faulted in. "dd", on the other hand, actually does "read"s from its input file (as proven by running "trace" on it), so "dd if=/vmunix of=/dev/null" does actually read all the data in "/vmunix", as opposed to "cp /vmunix /dev/null".