OnLine unreliable in filesystem files?

>But of course the kernel can keep track of this. The question is, when the >write() call returns to my app with a successful code, am I guaranteed that >the data is on disk? Scheduled for i/o, in this case, is not good enough. >My "paranoia" is based on real world experience. Please note that my motive is to take this conversation further than simply ruling OnLine use of fs objects as less reliable for the edification of those that AUGMENT OnLine performance on large queries by taking advantage of filesystem read-ahead. Of course we know that 6.0's tunable read-ahead is what we really need, but why freak people out by catagorically stating that OnLine is less reliable when using filesystem files when that is only true , by your own ommision, on implementations of Unix that can't even offer a real sync'ed write? If the Kernel can keep track of a sync'ed write, your process isn't comming out of Kernel-land until physical media is updated. A true sync'ed write should not boil down to an IO scheduling event. If it does, that implementation of Unix is one singularly huge bug. I know you see real world, Dave. Sequent sees real world on occasion too. In fact, something we're all looking forward to is sharing an exclusive real-world release of 6.1 PDQ for the first six months of production shipment. >Hold the phone here, Kevin. If it is possible for a data page to be "trapped >in the Unix cache at failure," how is it NOT possible for the same to occur >with log writes.... I made the point before reading your post in which you said ALL chunks are open()'ed O_SYNC. I presumed Online would open() the rootdbs O_SYNC and then figure out which chunks host logs and open them O_SYNC, but not the others... much like Oracle does. We can put this thread to rest if you could agree that as long as the flavor of Unix you are running REALLY offers a sync'ed write(2) on an fd open()'ed O_SYNC, and your logs are on such a file, fast-recovery will guarantee that there is no data loss up to the last committed Xaction prior to failure. What do you think? ________________ Kevin A. Closson, Senior Technical Support Engineer voice: (503)578-3072 World Wide Technical Support, Database Group FAX: (503)578-5453 Sequent Computer Systems 15450 SW Koll Pkwy (MS WIL1-502) UUCP: ..uunet!sequent!kevinc Beaverton, Oregon 97006-6063 internet: kevinc@sequent.com