On 2016-01-09 16:07, cheater00 . wrote:
Would like to point out that this can cause data loss. If I'm writing
to disk and the disk becomes unexpectedly read only - that data will
be lost, because who in their right mind makes their code expect this
and builds a contingency (e.g. caching, backpressure, etc)...
If a data critical application (mail server, database server, anything
similar) can't gracefully handle ENOSPC, then that application is
broken, not the FS. As an example, set up a small VM with an SMTP
server, then force the FS the server uses for queuing mail read-only,
and see if you can submit mail, then go read the RFCs for SMTP and see
what clients are supposed to do when they can't submit mail. A properly
designed piece of software is supposed to be resilient against common
failure modes of the resources it depends on (which includes ENOSPC and
read-only filesystems for anything that works with data on disk).
There's no loss of data on the disk because the data doesn't make it
to disk in the first place. But it's exactly the same as if the data
had been written to disk, and then lost.
No, it isn't. If you absolutely need the data on disk, you should be
calling fsync or fdatasync, and then assuming if those return an error
that none of the data written since the last call has gotten to the disk
(some of it might have, but you need to assume it hasn't). Every piece
of software in wide usage that requires data to be on the disk does
this, because otherwise it can't guarantee that the data is on disk.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
