On Thu, Feb 18, 2021 at 11:00:15PM -0500, Mouse wrote:
> > (3) I think the drawbacks of reporting user 1's I/O errors to user 2
> > [...] mean that we should guarantee that I/O errors from *your*
> > writes should be reported by *your* call to fsync. [...]
>
> > (3a) I don't think it's
> (3) I think the drawbacks of reporting user 1's I/O errors to user 2
> [...] mean that we should guarantee that I/O errors from *your*
> writes should be reported by *your* call to fsync. [...]
> (3a) I don't think it's necessary to guarantee that I/O errors from
> other people's writes won't
I have been going through various code paths (hence all the posts and
commits about obscure details) with an eye toward documenting what we
do and do not guarantee about files to applications... and I've gotten
to fsync.
In an ideal world, if you write some data and later when it gets
written to
On Thu, Feb 18, 2021 at 06:56:00PM -0500, Greg Troxel wrote:
> > And report any errors to me, so if you're a database and I'm feeling
> > nasty I can maybe mess with you that way. So I'm not sure it's a great
> > idea.
> >
> > Right now fsync error reporting is a trainwreck though.
>
> I
On Tue, Feb 16, 2021 at 05:29:00PM +0700, Robert Elz wrote:
> We could, of course, invent new interfaces (a write variant with an
> extra pointer to length written arg perhaps, or where the length arg
> is a pointer to a size_t and that is read and then written with either
> the amount
David Holland writes:
> Well, if you have it open for write and I have it open for read, and I
> fsync it, it'll sync your changes.
I guess maybe POSIX is wrong then :-)
But as a random user I can type sync to the shell.
> And report any errors to me, so if you're a database and I'm feeling
On Wed, Feb 17, 2021 at 01:17:14PM -0500, Greg Troxel wrote:
> > Last year, fdatasync() was changed to allow syncing files opened
> > read-only, because that ceased to be prohibited by POSIX and something
> > apparently depended on it.
>
> I have a dim memory of this and mongodb.
>
> >
