>> [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 [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
