[SERVER-16612] Implicitly zeroed files in WiredTiger Created: 19/Dec/14  Updated: 15/May/19  Resolved: 15/May/19

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Bruce Lucas (Inactive) Assignee: Donald Anderson
Resolution: Done Votes: 0
Labels: SEKB
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to WT-2151 explicitly zero'ing log files Closed
Sprint: Storage Engines 2019-05-20
Participants:
Story Points: 5

 Description   

There is a problem with the implicit zeroing of files by the kernel on certain platforms - see SERVER-15369 for more details. A workaround was put into place for this issue for mmapv1 files to explicitly zero .ns files.

The purpose of this ticket is to determine:

  • in what areas will WiredTiger have similar vulnerabilities to this issue?
  • what will be the customer impact of this issue to WiredTiger?
  • beyond advising customers to avoid using WiredTiger on platforms with the issue, can we reasonably work around the problem by explicitly zeroing all files rather than relying on the kernel's implicit zeroing?


 Comments   
Comment by Donald Anderson [ 15/May/19 ]

I think we're all in agreement here, I'm closing this.

Comment by Susan LoVerso [ 15/May/19 ]

Several years ago I added the log=(zero_fill=true) specifically in response to this ticket as part of WT-2151. I have linked that ticket into here. So anyone running an old or buggy version has the ability, at least for log files, to work around the issue.

Of course, that configuration setting puts the burden on the user to know to turn it on, but there is a path to mitigate the problem. And like everyone has said, we've never seen the problem actually manifest itself.

Comment by Keith Bostic (Inactive) [ 15/May/19 ]

I think it's unlikely, but possible, we could be fooled by a file that contained data from a different WiredTiger database, or the reuse of deleted blocks from the current WiredTiger database.

Because we store block information outside of the file's blocks (that is, block location and other information is stored separately from the file block itself), I think it less likely we'd be fooled in a data file (with the exception of when we ignore that separate information as part of performing a salvage on the file, as donald.anderson suggested). Because log files don't have a separation between blocks and block information, I think it's more likely we could be fooled in a log file, but still, I think we're likely to detect a problem and panic.

That said, I'm strongly of the same opinion as Don – this ticket was filed in response to a kernel bug from 5 years ago that fired on specific Linux releases running on VMWare using virtual SCSI disks managed by LVM, and which we've never seen in a WiredTiger install. I think we should close this one until we see a failure.

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