vitalif
/
fusego
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Wrote a novel on mmap'd files.

geesefs-0-30-9
Aaron Jacobs 2015-03-24 13:45:56 +11:00
parent a0d210e535
commit dd25450c72
1 changed files with 22 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
file_system.go
View File

@ -242,12 +242,28 @@ type FileSystem interface {
// case of close(2), a flush error is returned to the user. For dup2(2), it
// is not.
//
// Note that one potentially significant case where this is *not* called is
// munmap(2) (cf. http://goo.gl/j8B9g0). Even if users close(2) after writing
// to an mmap'd file, on OS X the contents are not immediately flushed (cf.
// https://github.com/osxfuse/osxfuse/issues/202). On both Linux and OS X
// users can get safe behavior by calling msync(2), then munmap(2), then
// close(2).
// One potentially significant case where this may not be called is mmap'd
// files, where the behavior is complicated:
//
// * munmap(2) does not cause flushes (cf. http://goo.gl/j8B9g0).
//
// * On OS X, if a user modifies a mapped file via the mapping before
// closing the file with close(2), the WriteFile calls for the
// modifications may not be received before the FlushFile request for the
// close(2) (cf. http://goo.gl/kVmNcx).
//
// * However, even on OS X you can arrange for writes via a mapping to be
// either fsync'd or flush'd by calling msync(2) followed by close(2). On
// OS X msync(2) will cause a write to go through and close(2) will cause
// a flush as usual (cf. http://goo.gl/kVmNcx). On Linux, msync(2) does
// nothing unless you set the MS_SYNC flag, in which case it causes an
// fsync (cf. http://goo.gl/P3mErk).
//
// In summary: if you make data durable in both FlushFile and SyncFile, then
// your users can get safe behavior from mapped files by calling msync(2)
// with MS_SYNC, followed by munmap(2), followed by close(2). On Linux, the
// msync(2) appears to be optional because close(2) implies dirty page
// writeback (cf. http://goo.gl/HyzLTT).
//
// Because of cases like dup2(2), calls to FlushFile are not necessarily one
// to one with calls to OpenFile. They should not be used for reference