[SERVER-18629] WiredTiger journal system syncs wrong directory Created: 22/May/15  Updated: 19/Jun/15  Resolved: 26/May/15

Status: Closed
Project: Core Server
Component/s: WiredTiger
Affects Version/s: 3.0.3
Fix Version/s: 3.0.4, 3.1.4

Type: Bug Priority: Critical - P2
Reporter: Bruce Lucas (Inactive) Assignee: Unassigned
Resolution: Done Votes: 1
Labels: FT
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on WT-1941 Sync the journal directory, not its p... Closed
Related
is related to SERVER-18314 Stall during fdatasync phase of check... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Completed:
Participants:

 Description   

While observing mongod behavior using strace and perf with dbpath (wt home) "/mnt/db" and journal (wt log) directory "journal" I noticed that it was calling fdatasync apparently unnecessarily on "/mnt/db" and never calling fdatasync on "/mnt/db/journal".

The reason is because __wt_log_open initializes log->log_dir_fh by calling __wt_open(session, "journal", ...), which expands the path to "/mnt/db/journal" before passing it to __open_directory. But __open_directory appears to expect the path to a file in the directory rather than the path of the directory, as it strips the final component of the path and opens "/mnt/db". The result is that the wt log system calls fdatasync on "/mnt/db" and not on "/mnt/db/journal".

There are two consequences to this:

  • Performance - the unnecessary fdatasync calls on /mnt/db can get stuck behind a lengthy call to fdatasync on a .wt file, or otherwise be hampered by i/o to .wt files; whereas an fdatsync call to /mnt/db/journal should be unimpeded by any activity in /mnt/db if the /mnt/db/journal has been placed on a separate drive, per our recommended best practices.
  • Durability - I believe durability of journaled writes depends on the fdatasync of /mnt/db/journal, in order to ensure that newly created journal files are durable.


 Comments   
Comment by Ramon Fernandez Marina [ 26/May/15 ]

Resolved in WT-1941.

Generated at Thu Feb 08 03:48:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.