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 Guide:
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 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