4 ms·
> How do you guarantee that, after a crash, the end of the file is at the end of some write? By updating the file size after the write. Note that Linux ext4 do
by kentonv 11y ago
> How do you guarantee that, after a crash, the end of the file is at the end of some write? By updating the file size after the write.
Note that Linux ext4 does not do this. On a power outage, you can get bogus trailing zeros on a file which you were appending, because the file size was updated before the data was written. I asked Ted T'so about this and he said it was working as intended.
https://plus.google.com/+KentonVarda/posts/JDwHfAiLGNQ https://plus.google.com/+KentonVarda/posts/JDwHfAiLGNQ
- ryao 11y agoZFS does do this. Changes are atomic, so they either happen or do not. There is no in-between.
- jstimpfle 11y agoI don't know about ZFS, but the usual write(2) API does not support this: It might for example return early with a short write because some interrupt occurred. Can happen for all "slow devices" (see signal(7)). And I think that's a good thing and am sure many programs expect this.
- kentonv 11y agoThe signal(7) man page also states clearly that a local disk is not a "slow" device, so this seems moot. read(2), readv(2), write(2), writev(2), and ioctl(2) calls on "slow" devices. A "slow" device is one where the I/O call may block for an indefinite time, for example, a terminal, pipe, or socket. If an I/O call on a slow device has already transferred some data by the time it is interrupted by a signal handler, then the call will return a success status (normally, the number of bytes transferred). Note that a (local) disk is not a slow device according to this definition; I/O operations on disk devices are not interrupted by signals.
- jstimpfle 11y agooops, had that wrong. Thanks for noticing!
- beagle3 11y agoIt does happen with the default setting, but if you journal everything, then it doesn't happen. Performance on spinning rust, however, drops 50%.
- x0 11y agoOh! So that's where all the random nulls in my shell history came from. Zsh would sometimes complain about a corrupted history after a bad crash, and I always wondered what caused maybe 20 nulls to be added to the end of the file. Thanks!