> 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/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:32 EST