[SERVER-7039] Investigate improving pre-allocation on NTFS Created: 13/Sep/12  Updated: 19/May/14  Resolved: 14/Sep/12

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

Type: Improvement Priority: Minor - P4
Reporter: Clifford Hammerschmidt Assignee: Ben Becker
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Issue Links:
Related
is related to SERVER-5819 Use FileAllocator on Windows Closed
Backwards Compatibility: Fully Compatible
Participants:

 Description   

Looks like there may be support for doing this better/faster than writing zeros to the file, see:

http://stackoverflow.com/questions/455297/creating-big-file-on-windows/455302#455302

(Use the Win32 API, CreateFile, SetFilePointerEx, SetEndOfFile, and CloseHandle.)



 Comments   
Comment by Ben Becker [ 14/Sep/12 ]

Hi Clifford,

Unfortunately this approach is not currently possible because setting the file pointer to EOF doesn't actually preallocate the data on disk. When using that approach, we found that some system calls (e.g. FlushViewOfFile) fail with lock violation errors. See SERVER-5819 and linked tickets for details.

For what it's worth, Mongo's data files do not grow, so the fragmentation issue mentioned in that link shouldn't be an issue (as far as I know). In general, we've found the current implementation to be fast on most machines as it performs a sequential write operation.

I'm going to go ahead and close this issue out, but please feel free to reopen it if you find preallocation is significantly slower than your disk's sequential write capabilities.

Thanks,
Ben

Comment by Tad Marshall [ 14/Sep/12 ]

This is a suggestion to undo the code changes we made to work around the Windows bug where FlushViewOfFile() would stall and falsely fail (return a failure code when there was no actual problem), so I don't think this would be a good change.

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