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