Skip to content
This repository has been archived by the owner on Mar 9, 2019. It is now read-only.

Add DB.NoTruncate flag. #363

Merged
merged 1 commit into from
May 6, 2015
Merged

Conversation

benbjohnson
Copy link
Member

Overview

This commit adds the DB.NoTruncate flag to optionally revert mmap() calls to how they were implemented before the ext3/ext4 fix. When NoTruncate is true, remapping the data file will not force the file system to resize it immediately. This works for non-ext3/4 file systems.

The default value of NoTruncate is false so it is still safe for ext3/ext4 file systems by default.

See also: #284

/cc @tv42 @mkobetic @bouk

@@ -55,6 +55,12 @@ type DB struct {
// THIS IS UNSAFE. PLEASE USE WITH CAUTION.
NoSync bool

// When true, skips the truncate call when resizing the database.
// Setting this to true is only safe on non-ext3/ext4 systems.
//
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be worth adding a note here the we found that Truncate can be very slow on some filesystems?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't able to determine the root cause. Truncation did work very quickly in some cases but in others it was taking >10m. It may have been a configuration issue or a hardware issue so I'd rather not assign blame to the FS.

Also, NoTruncate is nice if you don't want to preallocate space so I'll list that as a benefit.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated in 7a65f95.

@tv42
Copy link
Contributor

tv42 commented May 5, 2015

Can we call it something else than NoTruncate? First of all, the word truncate implies shortening, though it's the syscall used to adjust file size either way; here, it's used for growing. And the cost really comes from the sync.

Since technically it is, or might be depending on how to interpret the POSIX bible, ext3/ext4 etc that is at fault, I am not going to recommend UnsafeMetadata; as far as I understand, it's supposed to be safe without the truncate+sync, but it's not. NoMetadataSync?

@benbjohnson
Copy link
Member Author

I agree that NoTruncate sounds weird. The truncate() call is the one that is inexplicably hanging for us.

I have two issues with naming it NoMetadataSync:

  1. LMDB implements NOMETASYNC which sounds the same but works differently.
  2. It's only related to remapping. The name makes it sound like it always skips metadata sync.

How about NoRemapSync?

@tv42
Copy link
Contributor

tv42 commented May 5, 2015

NoGrowSync? NoSyncAfterGrow? NoSizeSync?

@benbjohnson
Copy link
Member Author

I think NoGrowSync would be my favorite from those three. Why not NoRemapSync?

@tv42
Copy link
Contributor

tv42 commented May 5, 2015

Because it's not really about mmap, either. Off hand, I think it even triggers on the first mmap, so it's really not a remap. The purpose of that code is to sync the new, larger, size of the file to disk.

This commit adds the DB.NoGrowSync flag to optionally revert mmap()
calls to how they were implemented before the ext3/ext4 fix. When
NoGrowSync is true, remapping the data file will not force the file
system to resize it immediately. This works for non-ext3/4 file
systems.

The default value of NoGrowSync is false so it is still safe for
ext3/ext4 file systems by default.

See also: boltdb#284
@benbjohnson
Copy link
Member Author

Changed to NoGrowSync. Merging. Thanks @tv42!

benbjohnson added a commit that referenced this pull request May 6, 2015
@benbjohnson benbjohnson merged commit fd65d6c into boltdb:master May 6, 2015
@benbjohnson benbjohnson deleted the no-truncate branch May 6, 2015 15:24
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants