----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/69009/#review209689 -----------------------------------------------------------
3rdparty/stout/include/stout/os/posix/fsync.hpp Lines 53-55 (patched) <https://reviews.apache.org/r/69009/#comment294240> Related to the discussion from https://reviews.apache.org/r/69009/#comment294039, I don't think this comment is correct. It seems we do not worry about the return value of `os::close` here since the previous `fsync` would already have triggered possible cases of `EIO`, `ENOSPC`, or `EDQUOT` (`EBADF` would already have been triggered by `os::open`). That would realistically only leave `EINTR` which we do truely do not care about. Let's update the comment, e.g., ``` We ignore the return value of `close()` since any I/O-related failure scenarios would already have been triggered when opening the file, or when invoking `fsync()`. ``` 3rdparty/stout/include/stout/os/posix/rename.hpp Lines 33-36 (patched) <https://reviews.apache.org/r/69009/#comment294241> This note is incorrect as this function could misbehave even in single-threaded programs. One such scenario would be when _another process_ removes `to` after the `rename`, but before the `fsync`. I am not sure how to properly address this in the implementation since `os::sync` doesn't return the error code from the `ErrnoError` generated in `os::fsync`, but only the sliced `Error`, so maybe we can only update the comment, e.g., ``` NOTE: This function can fail with `sync` set to `true` if either `from` or `to` get deleted before this function returns. [...] ``` 3rdparty/stout/include/stout/os/posix/rename.hpp Lines 47-48 (patched) <https://reviews.apache.org/r/69009/#comment294242> Do we also need to `fsync` `from`'s directory? If not, let's add a comment on why not. 3rdparty/stout/include/stout/os/write.hpp Lines 128-130 (original), 139-141 (patched) <https://reviews.apache.org/r/69009/#comment294243> This comment is still incorrect, especially with `sync=false`. I can file a follow up patch which should probably propagate a possible error from `os::close` if `result` wasn't already in an error state. - Benjamin Bannier On Oct. 16, 2018, 4:45 a.m., Chun-Hung Hsiao wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/69009/ > ----------------------------------------------------------- > > (Updated Oct. 16, 2018, 4:45 a.m.) > > > Review request for mesos, Andrew Schwartzmeyer, Benjamin Bannier, Jie Yu, and > Jan Schlicht. > > > Bugs: MESOS-9281 > https://issues.apache.org/jira/browse/MESOS-9281 > > > Repository: mesos > > > Description > ------- > > This patch adds an option for the caller to sync the file and directory > contents to the disk after a write to prevent filesystem inconsistency > against reboots. > > > Diffs > ----- > > 3rdparty/stout/include/stout/os/posix/fsync.hpp > 9a6bbf6c51b0a7d6085924733e33d8b4f1bbc1ac > 3rdparty/stout/include/stout/os/posix/rename.hpp > 9cff6db16c8a4e5a79bf0082e18a1133bd287796 > 3rdparty/stout/include/stout/os/windows/rename.hpp > 523912ac3bf315f70f542e8eab7d2d02249909b4 > 3rdparty/stout/include/stout/os/write.hpp > cd35285a9595004bac627abf687588050aef8161 > 3rdparty/stout/include/stout/protobuf.hpp > 1d03e1e3a8dd642f7239d777fb04759caf100a8b > > > Diff: https://reviews.apache.org/r/69009/diff/3/ > > > Testing > ------- > > make check > > > Thanks, > > Chun-Hung Hsiao > >
