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