On Mon, 22 Feb 2010 17:36:01 -0500 (EST) der Mouse <mo...@rodents-montreal.org> wrote:
> > I have a question reguarding mmap(2)ed files which are modified. > > Modified through the mmapped memory, I take it you mean? (They can > also be modified through the filesystem interface, and most of the > interesting questions hinge on having two different access paths to a > single set of bytes.) Right, modified via the mapped memory. > > After reading the manual page of msync(2), I have the impression that > > if invoked with the MS_SYNC flag, it should be safe enough not to > > need a further fdatasync(2)/fsync_range(2) call afterwards? > > That's my own impression too - indeed, it'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. It's at least as > fd-specific as the fsync() you mention below. Indeed, and if I remember after mmap(2) a descriptor can be closed before doing operations on the file, so it's no longer even attached to an FD per say, I think. > Is that how the current implementation works? I don't know. I have no idea, but that's why I used tech-kern over tech-userlevel for these questions, as there probably are some around familiar with the implementation :) > > Also, I am auditing an application which seems to modify mmaped files > > but which does not use msync(2) at all (and I can see that an older > > fsync(2) call was used, but is now commented out). Should this be > > considered a bug? > > In my opinion? No, unless access to the same files via filesystem > methods needs to be coherent with the mmap()ped view. Maybe not even > then, depending on things you haven't told us (eg, how restricted the > target OS scope for the thing is - some things that are bugs if it's > supposed to run on anything POSIX may not be fine if, say, anything > except SunOS 4.1.1 on a SPARCstation-4 is out of scope). The application in question doesn't use mmap() for sharing in this case, but probably for the convenient random-access performance (to maintain a bitmap file). 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... Thanks, -- Matt