On 2016-01-11 08:11, cheater00 . wrote:
On Mon, Jan 11, 2016 at 2:05 PM, Austin S. Hemmelgarn
<ahferroin7@xxxxxxxxx> wrote:
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.
I agree that a lot of stuff goes right in a perfect world. But most of
the time what you're running isn't a mail server used by billions of
users, but instead a bash script someone wrote once that's supposed to
do something, and no one knows how it works.
And that's why no sane person does stuff like that on enterprise level
systems. And even then, if the person writing the bash script actually
knows what they're doing, they will be using the 'sync' command to
ensure data integrity when they actually need it, or they will write
their script in such a way that it gracefully handles a partial run.
--
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
