[geocar]

> Isn’t this addressed by preallocating data files in advance of writing application data?

Allocation isn't the only thing that can fail: Actually writing to the blocks can fail, and just because you can write zeros doesn't mean you can write anything else.

You really can't know until you try. This is life.

[beng-nl]

You’re not wrong, but you are moving the goalposts a little; GP is responding to your “disks is going to be full” scenario, and that is well handled I’d say by pre allocation.. then of course other things can go wrong too.

[geocar]

Yes things can go wrong. That's the point. The problem is what to do about it.

I think if you needed a better example of something you can't defend against in order to get the main idea, that's one thing, but I'm not giving advice in bad faith: Can you say the same?

[zaphirplane]

The person you are replying to, has a reasonable position and explained it well. IMHO

[geocar]

No they really don't.

fallocate() failing is exactly the same as write() failing from the perspective of the user, because the disk is still full, and the user/operator responds exactly the same way (by waiting for cleanup, deleting files, adding storage, etc).

Databases (the example given) actually do exactly as koolba suggests, and ostensibly for the reason of surfacing the error to the application. The point is what to do about the error itself though, not about whether fallocate() always works or is even possible.