-----------------------------------------------------------
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
>
>
|