Re: RHEL5/

  • From: Maureen English <sxmte@xxxxxxxxxxxxxxxx>
  • To: Oracle-L Freelists <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 11 Aug 2009 15:39:31 -0800

FYI, from one of our sysadmins:

Not having consistent modifications times is a "feature" of OCFS2.  What
you are seeing is probably related to the following from the OCFS2 User's

Modifications Times

To allow multiple nodes to concurrently stream I/Os to an Oracle datafile,
OCFS2 makes a special dispensation from the POSIX standard by not updating
the modification time (mtime) on disk when performing non-extending direct
I/O writes. To be precise, while the new mtime is updated in memory, it is
not flushed to disk unless the user extends or truncates the file or
performs an explicit operation, such as touch(1). This dispensation leads
to the file system returning differing time stamps for the same file on
different nodes. While this is not ideal, this behavior exists to allow
maximum throughput.  Updating mtime on each write would negate one of the
main benefits (parallel I/O) of a clustered database, because it would
serialize the I/Os to each datafile.

User wishing to view the on-disk timestamp of any file can use the
debugfs.ocfs2 tool as follows:

$ debugfs.ocfs2 -R "stat /relative/path/to/file" /dev/sda1 | grep "mtime:"

- Maureen

Maureen English wrote:

I just moved a database from one filesystem to another, edited the
init.ora file to find the control files in the correct location,
started up the database, renamed all of the datafiles, logfiles and
tempfiles, and opened the database.  No errors were reported and I
could connect to the database and do some simple queries.

One of my checks was to verify log rolls.  The alert log shows log
rolls, but the timestamps on all of the files are from April 24!
It's likely that nothing changed since April 24th, but I really did
expect to see changes from today, especially timestamps on the log

Has anyone else seen this behavior?  When I looked further, I found
that the same is true for all of our RHEL5 databases.

Any comments?

- Maureen



Other related posts: