[Ocfs2-users] Ocfs2-users Digest, Vol 88, Issue 3

[David Johle]

>Message: 5
>Date: Fri, 1 Apr 2011 21:14:15 +0100
>From: John Gardner <John.Gardner at southtyneside.gov.uk>
>Subject: Re: [Ocfs2-users] Anomaly when writing to OCFS2
>To: Sunil Mushran <sunil.mushran at oracle.com>
>Cc: "ocfs2-users at oss.oracle.com" <ocfs2-users at oss.oracle.com>
>Message-ID:
>         <0EF7337F42B8B0428C06290DC305EA4302ECB4C4FBFC at ST1AA2V00009.stc.local>
>Content-Type: text/plain; charset=us-ascii
>
> >So everything works fine as long as the temp file is being written to.
> >The out file is the issue.
>
>Not exactly, the temp file is always written to whether the temp 
>file is located on OCFS2 or sym linked to the EXT3 partition.  The 
>problem occurs right at the end of the process;
>
>When tmp file is located on OCFS2, the log file is written to it, 
>the log file completes, creates the out file (wth nothing in it) and 
>resets the tmp file to 0kb.
>When tmp file is located on EXT3, the log file is written to it, the 
>log file completes, creates the outfile and copies the contents to 
>it, then resets the tmp file to 0kb.
>
> >How is the file copied from temp to out?
> >mv? cp?
> >And please don't guess.
>
>This copying action is a standard Oracle Concurrent Manager action 
>so I have no way of knowing how Oracle is programmatically 
>performing this, as it is Oracle code.
>
>Regards
>
>John



It sounds to me like the Oracle process isn't actually copying the 
file, but cheating and using a hard link.  So when you have this out 
file, it's actually a pointer to the same inode that the log file 
points at.  Then, when you zero the log file, you are truncating the 
same inode shared with the out file, thus it gets truncated as 
well.  However, if this were the case, subsequent writes to the log 
file should be visible in the out file as well.  Is that the case?

Also, if the above is the case, it makes sense that this behavior 
doesn't happen when the log and out files are on different 
filesystems as you cannot hard link across that boundary, thus it 
makes a proper copy instead.

It might be interesting to use tools like strace and blktrace to see 
what the Oracle program is really doing at the I/O layer in each scenario.