mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Bannier <benjamin.bann...@mesosphere.io>
Subject Re: Review Request 69009: Stout: Added a sync option for `write` and `rename`.
Date Wed, 17 Oct 2018 09:52:14 GMT

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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message