Re: Raw I/O vs files (was Re: Raw partitions / cooked files)

In article <1993Jul29.112058.20676@pyra.co.uk> graeme@uk.pyramid.com (Graeme Sargent) writes: >In <2506@coyote.UUCP> gainer@slowmo.almaden.ibm.com (P. Gainer) writes: > >>In a recent append, lparsons@exlog.com (Lee Parsons) writes... > >[stuff deleted] > >>And this is what I am curious about. What are the "small" perf gains? >>Are they worth the expense of avoiding the filesystem altogether? > >>>I think that is because you, I and everybody else already know the >>>answer. The only way your are going to see a *significantly* faster >>>raw benchmark is if something else somewhere is not tuned well. > >>I don't necessarily think this is true. If you look at the TPC-A/B/C >>benchamrks, all the leaders get their numbers using raw I/O. This implies >>raw I/O can be faster when tuned. Without actually doing a huge benchmark >>comparison, I would be curious to know what others have observed. > >>How many DBAs are running Oracle/Informix/etc etc using raw I/O? Any? > >With OnLine, Informix have always recommended that raw i/o should be the >default choice, and that cooked i/o only be used for demo, training or >development databases etc. > [...] Some time ago there has been a (small) discussion about raw / cooked files systems with Sybase - it was mentioned, that the advantage of raw devices over cooked file systems lies in the enhanced control of the DBMS over what is going on on the disk - e.g., it was said, that it is more difficult to say, when data is really written onto the disk on a cooked filesystem than on a raw filesystem, where all the control over it lies in the hands of the DBMS. It was also said, that for this reason one should use raw devices when one can do it (similar to the above informations about Informix). It will be rather difficult to recover from system failures when one does not know exactly the state of all the recovery processes. [...] Thomas Mack Universitaet Braunschweig, Abtl. Datenbanken