Re: msync(2)

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> [I]t's not clear to me that fdatasync has any bearing; it's not
>> clear to me that an mmapped memory range is "data associated with"
>> any file descriptor.
> Indeed, and if I remember after mmap(2) a descriptor can be closed
> before doing operations on the file,

Well, before reading/writing the mapped memory; after closing the
descriptor, there's no handle to perform other operations via.

> [...mmapped data...]  I've seen inconsistent data after a crash a few
> times when using WAPBL, but not with softdep.  That said, the
> application could very well be using mmap unsafely...

"Unsafely"?  In the face of what threat model?

It's hard to get data coherency guarantees out of mmap() in the face of
"whole machine abruptly loses power" or equivalent threats; in general
you don't even have write ordering preservation (you do in some special
cases, such as with respect to writes that are wholly contained within
the same block, where a "block" is the smaller of a disk sector and a
VM page, but knowing that requires unwarranted chumminess with the
implmentation).

Strictly speaking, you don't even have that with disks, these days,
with write-back caches and the like.  But with disks, even if it's not
guaranteed in theory, you generally have it in practice; with mmap(),
this is not so.

Graceful shutdowns, of course, should be fine.  Even relatively
controlled crashes - kernel panics for which dirty-page sync works -
will usually be OK, though of course every panic is a can't-happen and
thus can't really guarantee anything.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B