CODEWITHSUNDEEP
clinuxfilesystemsmmap
Jérôme Pouiller
Jérôme Pouiller

Reputation: 10267

Atomicity of writing in a file with mmap?

One way to modify content of a file is run mmap with flag MAP_SHARED and then write in memory region returned. For example:

struct data *data;
const int size = sizeof(struct data);
int fd = open("data_file", O_RDWR);
ftruncate(fd, size);
data = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
/* Access to 'data' members */

Let's consider I use a journalized filesystem (ext4 with data=ordered or data=journal). What precautions I should take in order to allow to recover data from data_file after a power outage?

IMO, Linux guarantees that write operations will be ordered but it does not guarantee any atomicity. Therefore, application have to implement a kind of journal in order to recover data_file (as most databases do). Do you confirm that?

Upvotes: 3

Views: 1834

Answers (1)

Andrew Henle
Andrew Henle

Reputation: 1

What precautions I should take in order to allow to recover data from data_file after a power outage?

Since there's no way you can guarantee true atomicity of updates to mmap()'d memory, you need to do two things:

  1. Use a mutex or other synchronization mechanism to protect keep your data in as consistent a state as possible
  2. Use msync() to force data to be written to disk after any update.

Note that since you can't prevent mmap() data from being written to disk without an msync(), this is vulnerable to non-atomic updates to data on disk, although that risk can be minimized if your updates never cross a page boundary. You'd have to have a failure in the middle of an update to your object, and you'd have to have the OS write that page to disk while in the middle of your transaction.

If you place the mutex or other synchronization object within the mmap()'d data itself, I suspect the act of obtaining the mutex will cause an update in the mmap()'d memory that would delay any writing of data. Placing the mutex in the data itself would likely complicate recovery, though as long as you could ensure recovery is single-threaded, that shouldn't be much of a problem to work around if it can't be entirely ignored.

A better solution to this recovery problem would be to not use mmap() and explicitly write the data in a way that guarantees an all-or-nothing update, but I suspect that would have significant other impacts on your design.

Upvotes: 2

Related Questions