Boost logo

Boost Users :

Subject: Re: [Boost-users] [interprocess] Fault recovery in managed mapped file
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2010-11-18 15:07:53


On 17/11/2010 15:14, Kevin Arunski wrote:
> I have found that managed mapped file can get stuck in a spinlock if the
> file is not closed and fully flushed to disk. For example, if the power
> is pulled from computer while a segment is open and before the first
> page in the segment has been committed. In this case it is common for a
> journaled filesystem to preserve the fact that the file was created, but
> it has lost the contents of the file and now the file appears to be
> zero'd out. I have observed this behaviour on Linux systems running
> ext4, for example.

> Some possible solutions:
>
> If, at this point we have opened a file and not created it, why wait for
> an UnitializedSegment to change state? If the segment is Unitialized
> here then simply throw an error. Make it the caller's responsibility to
> ensure the segment is created/initialized before it opened in a
> read-only mode.

The reason is to support simultaneous open and create, as you indicate
below.

> Perhaps, if you want to allow multiple processes to do open and create
> simultaneously without any additional synchronization mechanism, you
> could accomplish that by adding a count of open mappings into the shared
> segment. If the reference count is 1 at this point, don't attempt this
> spinlock because the state of the file is never going to change. In this
> case throw if the *patomic_word is != InitializedSegment.

A count does not work, because if a process dies, then you have a wrong
count. If you need to commit the first page to avoid power errors, call
flush() just after creating the managed segment.

Anyway, trying to use a mapped file after a hard shut down has no
sensible recovery, you don't know which parts of the file the OS has
committed, the internal data structure might be absolutely corrupted.

Best,

Ion


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net