Re: write to disk in cooked files

David Kosenko wrote: > > Also sprach Neil Truby <ntruby@netcomuk.co.uk> : > :guest wrote: > :> > :> Hi , > :> When we are using cooked files , when a write is issued by informix to the > :> OS "UNIX" it returns a write successful . Now my question is where exactly is > :> the write performed i.e to the buffer or to the disk ? > : > :Well, the point is, you don't know. And becuase you can't be certain > :that the write HAS actually gone to disk, as Informix assumes it has, > :you have potential data integrity problems. > : > :This is why, correctly in my opinion, Informix recommend that you use > :raw disk for important (ie non-development) systems. An exception is, > :arguably, temporary dbspaces. > > Well, yes and no. Indeed, what Niel writes is the conventional wisdom. > However, for some number of years now, Informix has been opening chunks with the > O_SYNC flag (I know - I peeked at the source), which, on a well-behaved Unix > system, causes the write to be flushed to disk immediately, i.e. the data won't > be hanging about in a Unix f/s buffer somewhere. What this in turn does to your > i/o performance is another matter. But the data *should* be getting to disk. Dave is correct, the safety issue of cooked files is no longer a problem. The big problem with cooked files still is performance. All writes and reads to/from cooked files MUST go through the UNIX buffer cache. This means an additional copy from the server's output buffer to the UNIX buffer page then a synchronous write to disk. This is opposed to a write to a way file where the server's output buffer is written directly to disk without the intervening copy. This is just faster. Anyone who has written anything that can test this can attest to the difference in speed. Here are my test results: FileType Sync? Times (real/user/system) 2run avg --------------- ----- ----------------------------------------- Filesystem file N 14.40/3.70/2.52 Y 15.02/3.61/2.63 Cooked disk N 12.81/3.74/2.24 Y 13.42/3.84/2.43 Raw disk N 9.32/3.67/1.52 Y 9.40/3.66/1.44 From this you can clearly see the cost of Cooked files and of synced cooked files. The tests were done with a version of my ul.ec utility modified to optionally open the output file O_SYNC. Cooked disk partition is almost 50% slower than raw disk partition and cooked filesystem files are almost 60% slower. The penalty for O_SYNC is an additional 5% for cooked files and negligible for RAW files (as expected). The test file was 2.85MB written using 4K I/O pages (the default fopen application buffer size) which should simulate Informix performance. The Cooked and Raw disk partition tests were conducted to a singleton 9GB Fast Wide SCSI II drive using the raw and cooked device files corresponding to the same drive. Art S. Kagel