Re: 2.4.18 no timestamp update on modified mmapped files

From: Andrew Morton (
Date: Wed Jun 12 2002 - 02:56:25 EST

Alan Cox wrote:
> > On Tue, 11 Jun 2002, Andrew Morton wrote:
> > >
> > > I think it's too late to fix this in 2.4. If we did, a person
> > > could develop and test an application on 2.4.21, ship it, then
> > > find that it fails on millions of 2.4.17 machines.
> >
> > Oh, please reconsider that! Doesn't loss of modification time
> > approach data loss? Surely we'll continue to fix any data loss
> > issues in 2.4, and be grateful if you fixed this mmap modtime loss.
> It doesnt approach data loss, when doing incremental backups it
> *is* data loss. Ditto with rsync --newer

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).

2: Resurrect delayed-allocation patches, use their reservation
   API to generate the SIGBUS.

3: Record the fact that there has been a data loss in the mapping
   and return that information to a subsequent msync(). (I have
   most-of-a-patch for this. It's fairly murky).

4: Dirty the page again if writepage() failed. This fills the machine
   up with unfreeable pages, but emitting ENOSPC messages into the
   logs may be acceptable - the operator makes some space, the data
   gets written and the messages stop.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:24 EST