"Matthew Nuzum" <[EMAIL PROTECTED]> writes: > I have colinux running on a Fedora Core 1 image. I have the rhdb 3 (or > PostgreSQL RedHat Edition 3) on it running. Here are tests with fsync on > and off: > FSYNC OFF FSYNC ON RUN > 136.9 142.0 124.5 149.1 1 > 122.1 126.7 140.1 169.7 2 > 125.7 148.7 147.4 180.4 3 > 103.3 136.7 136.8 166.3 4 > 126.5 146.1 152.3 187.9 5 > 114.4 133.3 144.8 176.7 6 > 124.0 146.5 143.3 175.0 7 > 121.7 166.8 147.8 180.5 8 > 127.3 151.8 146.7 180.0 9 > 124.6 143.0 137.2 167.5 10 > -------------------------------------- > 122.7 144.2 142.1 173.3 AVG > > I hope those numbers' formatting come through all right.
No, they didn't. You used tabs? Are they four space tabs or 8 space tabs? I assume 4 space tabs, but then what is the meaning of the four columns? You have two columns for each fsync setting? One's under Windows and one's under Vmware? Which is which? > It occurs to me that the fsync may be performed to the linux filesystem, but > this filesystem is merely a file on the windows drive. Would Windows cache > this file? It's 2GB in size, so if it did, it would only be able to cache > part of it. Well VMWare certainly doesn't know that the linux process called fsync. For all it knows the Linux kernel just schedule the i/o because it felt it was time. So the question is how does VMWare alway handle i/o normally. Does it always handle i/o from the Guest OS synchronously or does it buffer it via the Host OS's i/o system. I'm actually not sure which it does, it could be doing something strange. But does seem most likely that it lets Windows buffer the writes, or does so itself. It might also depend on whether you're using raw disks or a virtual disk file. Undoable disks would throw another wrench in the works entirely. Note that "caching" isn't really the question. It doesn't have to cache the entire 2GB file or even very much of it. It just has to store the block that linux wants to write and report success to linux without waiting for the disk to report success. Linux will then think the file is sync'd to disk and allow postgres to continue with the next transaction without actually waiting for the physical disk to spin around to the right place and the head to seek and perform the write. -- greg ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])