4 ms·
I'm pretty sure it does affect any database/application relying on buffered I/O. Even if you use the fsync() interface correctly, you're still affected by the b
by pgaddict 8y ago
I'm pretty sure it does affect any database/application relying on buffered I/O. Even if you use the fsync() interface correctly, you're still affected by the bugs in error reporting.
- hyc_symas 8y agoTechnically there is no bug in error reporting. fsync() reported an error as it should. The application continued processing, instead of stopping. fsync() didn't report the same error a second time, which leads to the app having problems. The application should have stopped the first time fsync() reported an error. LMDB does this, instead of futile retry attempts that Postgres et al do. Fundamentally, a library should not automatically retry anything - it should surface all errors back to the caller and let the caller decide what to do next. That's just good design.
- pgaddict 8y agoNo. Kernels before 4.13 may or may not report the fsync error correctly, depending on various conditions. There are more details in the talk [1] I posted earlier, and in the LWN articles related to this issue. [1] https://www.youtube.com/watch?v=74c19hwY2oE https://www.youtube.com/watch?v=74c19hwY2oE
- hyc_symas 8y agoAh I see. https://lwn.net/Articles/718734/ https://lwn.net/Articles/718734/ Someone issuing a sync() could cause an error to be cleared before the app's fsync() happens. That's a drag.