You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 16, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Jul 16, 2022. It is now read-only.
While safer, I'm not sure this is desirable behavior on e.g. SSDs (where small
writes are damaging).
Overall fsync provides the amount of "safety" I've come to expect. I haven't
seen any other impl do anything special for OS X and therefore assumed that my
level of "safety" is sufficient.
That said: We probably want this, but with a flag to turn it off in
performance-critical situations.
On Wed, Dec 02, 2015 at 04:51:37AM -0800, Christoph Reiter wrote:
I think this is missing
if hasattr(fcntl, "F_FULLFSYNC"):
fcntl.fcntl(f.fileno(), fcntl.F_FULLFSYNC)
else:
os.fsync(f.fileno())
on OSX.
As mentioned here [0] and here [1] fsync doesn't wait for the changes to hit the disk there.
After re-reading this I'm not sure if it's always expected that we block for the data to hit the disk. As long as it doesn't linger in the cache for too long (> 1sec, for example), it should be fine, no?
I would use F_FULLFSYNC on OS X. If fsync doesn't ensure that data is written into permanent storage (and the on-disk cache doesn't have battery backup), the operation is neither atomic nor durable.
As long as it doesn't linger in the cache for too long (> 1sec, for example)
But there are no guarantees for this. The data can linger in the cache for an arbitrary amount of time.
Activity
untitaker commentedon Dec 4, 2015
While safer, I'm not sure this is desirable behavior on e.g. SSDs (where small
writes are damaging).
Overall
fsyncprovides the amount of "safety" I've come to expect. I haven'tseen any other impl do anything special for OS X and therefore assumed that my
level of "safety" is sufficient.
That said: We probably want this, but with a flag to turn it off in
performance-critical situations.
On Wed, Dec 02, 2015 at 04:51:37AM -0800, Christoph Reiter wrote:
untitaker commentedon Jul 26, 2016
@Unrud Do you have any opinion on this?
untitaker commentedon Jul 26, 2016
After re-reading this I'm not sure if it's always expected that we block for the data to hit the disk. As long as it doesn't linger in the cache for too long (> 1sec, for example), it should be fine, no?
Unrud commentedon Jul 26, 2016
I would use
F_FULLFSYNCon OS X. Iffsyncdoesn't ensure that data is written into permanent storage (and the on-disk cache doesn't have battery backup), the operation is neither atomic nor durable.But there are no guarantees for this. The data can linger in the cache for an arbitrary amount of time.
The same problem seems to exist on Windows.
untitaker commentedon Jul 26, 2016
It seems my reading comprehension is getting worse. Will implement as-is.
Use F_FULLSYNC on OS X
Use F_FULLSYNC on OS X
Use F_FULLSYNC on OS X
Use F_FULLSYNC on OS X
Use F_FULLSYNC on OS X
Use F_FULLSYNC on OS X
[-]Support OSX[/-][+]Proper fsync on OS X[/+]untitaker commentedon Jul 26, 2016
See #18 for Windows
Use F_FULLSYNC on OS X (#16)