Messages in this thread | | | Date | Sat, 15 Jun 2002 15:24:43 +1000 | Subject | Re: 2.4.18 no timestamp update on modified mmapped files | From | Kevin Easton <> |
| |
> On Wed, 12 Jun 2002, Andrew Morton wrote: > > > > A more serious form of data loss occurs when an application has a shared > > mapping over a sparse file. If the filesystem is out of space when > > the VM decides to write back some pages, your data simply gets dropped > > on the floor. Even a subsequent msync() won't tell you that you have > > a shiny new bunch of zeroes in your file. > > > > It's not simple to fix. Approaches might be: > > > > 1: Map the page to disk at fault time, generate SIGBUS on > > ENOSPC (the standards don't seem to address this issue, and > > this is a non-standard overload of SIGBUS). > > > I've looked at this issue in the past: it's a familiar problem > for various filesystems on various flavours of UNIX. Some of the > strangeness in tmpfs (shmem_recalc_inode, or ac's shmem_removepage) > can be traced to this issue, I believe. The filesystem does not > know when a clean page is dirtied, and somehow has to cope afterwards. > > > I believe your option 1 is closest to the right direction; and SIGBUS > is entirely appropriate, I don't see it as a non-standard overload. > > > But you didn't spell out the worst news on that option: read faults > into a read-only shared mapping of a file which the application had > open for read-write when it mmapped: the page must be mapped to disk > at read fault time (because the mapping just might be mprotected for > read-write later on, and the page then dirtied). >
Can't the page be mapped to disk at the page-dirtying-fault time? I was under the impression that even after the mapping has been mprotected for read-write, the first write to each page will still cause a page fault that results in the page being marked dirty.
- Kevin.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |