----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/69009/#review209538 -----------------------------------------------------------
3rdparty/stout/include/stout/os/posix/rename.hpp Lines 41 (patched) <https://reviews.apache.org/r/69009/#comment294037> While POSIX guarantees that `rename` e.g., does not see inconsistent state, there is nothing preventing `to` from being deleted once we execute the conditional code here. Since it is hard to know what semantics users expect _in general_, it might make more sense to not add the sync behavior to `rename`, but to e.g., ask users to perform `fsync` themself. 3rdparty/stout/include/stout/os/write.hpp Lines 119 (patched) <https://reviews.apache.org/r/69009/#comment294040> I personally find flag arguments hard to read (`write(.., .., false)` or `write(.., .., true)` are not obvious). I'd suggest to either introduce a dedicated `write_sync` function or let callers trigger the `fsync`. 3rdparty/stout/include/stout/os/write.hpp Lines 133-134 (patched) <https://reviews.apache.org/r/69009/#comment294038> Is the performance impact in the comment common knowledge? I would have expected that implementation asked to `write` with `O_SYNC` could internally perform the equivalent of what we are doing by hand here. If possible just use `O_SYNC` with `os::open` above. 3rdparty/stout/include/stout/os/write.hpp Lines 128-130 (original), 138-140 (patched) <https://reviews.apache.org/r/69009/#comment294039> Not yours and not affecting the `sync=true` case, but I wonder whether this comment is correct; e.g., with NFS mounts I'd expect a `write` to succeed with the error only surfacing on `close` when the data is likely flushed. 3rdparty/stout/include/stout/os/write.hpp Lines 152 (patched) <https://reviews.apache.org/r/69009/#comment294041> Ditto. 3rdparty/stout/include/stout/protobuf.hpp Line 136 (original), 139 (patched) <https://reviews.apache.org/r/69009/#comment294042> See comment below on `os::write` on the `sync` flag. 3rdparty/stout/include/stout/protobuf.hpp Lines 149-151 (original), 158-160 (patched) <https://reviews.apache.org/r/69009/#comment294043> See comment below. 3rdparty/stout/include/stout/protobuf.hpp Lines 172 (patched) <https://reviews.apache.org/r/69009/#comment294044> Ditto. - Benjamin Bannier On Oct. 13, 2018, 1:53 a.m., Chun-Hung Hsiao wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/69009/ > ----------------------------------------------------------- > > (Updated Oct. 13, 2018, 1:53 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/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/2/ > > > Testing > ------- > > make check > > > Thanks, > > Chun-Hung Hsiao > >
