Re: Raw partitions / cooked files

kevinc writes: ( I had written): |> >That is only true if the o/s provides *guaranteed* synced writes. We do |> >open all chunks with O_SYNC, but even still this is not 100% reliable across |> >all platforms. |> |> I advocate raw IO for OnLine, but I think there is an amount of paranoia |> in thinking that there is an implementation of Unix where the Kernel can't |> keep track of whether or not the physical IO behind a sync'ed write occurred. 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. |> Since the log has integrity due to sync'ed writes, AND ALL COMMITTED |> TRANSACTIONS ARE RE-APPLIED at fast-recovery, where is the data loss if some |> modified data page is trapped in the Unix cache at failure. The before image |> page is available and that's all that matters. 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? Since we do all opens of chunks with O_SYNC, the write is either done for sure (in both cases) or not (potentially for both). You can't have it both ways, as you seem to imply above. Dave Disclaimer: These opinions are not those of Informix Software, Inc. ************************************************************************** "I look back with some satisfaction on what an idiot I was when I was 25, but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney