Messages in this thread | | | Date | Wed, 12 Jun 2002 00:56:25 -0700 | From | Andrew Morton <> | Subject | Re: 2.4.18 no timestamp update on modified mmapped files |
| |
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 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/
| |