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/