Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-5662

Discuss if verify should have a "history-store" option or use history-store URI instead

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.4.0
    • Affects Version/s: None
    • Component/s: None
    • None
    • 1
    • Storage - Tora 2020-05-04

      While addressing review for WT-5556 there was a discussion around whether we should add a "history-store" flag to the verify API or pass uri = "file:WiredTigerHS.wt" instead:
      https://github.com/wiredtiger/wiredtiger/pull/5291#discussion_r382955148

      I am filing this ticket to continue that discussion here. For completion I am copy-pasting the conversation here:

      @keithbostic yesterday Member
      I'm confused why we need -a, I'm sure I'm missing something obvious, but couldn't we verify the file:WiredTigerHS.wt uri?
      
      @sulabhM 2 hours ago Author Member
      At the moment verifying file:WiredTigerHS.wt will attempt to verify the internal contents of the history store file and fail at trying to obtain the lock. There is a ticket open to find a way to get past the exclusive access requirement, WT-5352.
      
      The idea behind having a separate flag/option is that we can add more history-store specific checks behind that flag and not just limit to file verification. Also, it is cleaner to call it through API, as a configuration option, "history-store":true, instead of URI as "file:WiredTigerHS.wt".
      
      Alternatively, we can strcmp the passed URI with "file:WiredTigerHS.wt" and do additional checks if there is a match, but I think passing an API option is cleaner for the end-user.
      
      @keithbostic 30 minutes ago Member
      I disagree, but I won't fight to the death on this one. To lay out the case:
      
      First, this is a debugging option, end-users won't ever call it and it's a rare option for even developers, so I'm pretty comfortable not having a shorthand to get to the functionality. End-users don't actually care if the history file is verifiable, as long as it delivers the correct results for the other files in the system, with luck they won't even be aware of it.
      
      Second, as you say, we can do whatever we like by looking at the URI, and in fact, that's what we're doing for all URIs, by looking at the history store as well as the passed in URI argument. So, adding an option doesn't add functionality. (We've didn't do anything like this for the metadata file, or the lookaside file, I'm not sure how the use cases change for the durable history file.)
      
      Finally, there's a limit to the verification we can do without an exclusive lock: we need to think a bit about how this changes the meaning of "verification". If we do go down that route, perhaps we should offer a "verification light" for all verifications, not just the durable history file.
      
      @sulabhM 3 minutes ago Author Member
      "file:WiredTigerHS.wt" is an internal name, my preference is to hide it when specified as part of the API. If you disagree we can continue that discussion in WT-5662.
      

            Assignee:
            sue.loverso@mongodb.com Susan LoVerso
            Reporter:
            sulabh.mahajan@mongodb.com Sulabh Mahajan
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: