Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-1726

Last modification time for database files could be misleading

    XMLWordPrintableJSON

Details

    • Icon: Task Task
    • Resolution: Won't Fix
    • Icon: Major - P3 Major - P3
    • None
    • None
    • production
    • None

    Description

      On Red Hat Enterprise Linux Server release 5.9 and MongoDB 2.4.5 the last modification time on mongodb data files is not updated when they are flushed. But changing the Operating System to RHEL 6.4, I can see that the last file modification time is updated correctly.

      It looks like the 2.6.18 RHEL Linux kernel doesn't conform to:

      http://pubs.opengroup.org/onlinepubs/007908799/xsh/mmap.html


      The st_atime field of the mapped file may be marked for update at any time between the mmap() call and the corresponding munmap() call. The initial read or write reference to a mapped region will cause the file's st_atime field to be marked for update if it has not already been marked for update.

      The st_ctime and st_mtime fields of a file that is mapped with MAP_SHARED and PROT_WRITE, will be marked for update at some point in the interval between a write reference to the mapped region and the next call to msync() with MS_ASYNC or MS_SYNC for that portion of the file by any process. If there is no such call, these fields may be marked for update at any time after a write reference if the underlying file is modified as a result.


      However the 2.6.32 version of kernel works as expected. That makes me believe that the issue was caused by the Linux kernel bug and there is no data loss involved, if the file last modification time was the only one inconsistent sign.

      Attachments

        Activity

          People

            Unassigned Unassigned
            alex.komyagin@mongodb.com Alexander Komyagin
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:
              10 years, 29 weeks ago