Maximilian Lorlacks wrote:
> This looks okay to me.
>
> (plus two months ping)
oh, good news, committed two months ago. sorry, forgot to reply.
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, April 16, 2019 8:19 PM, Ted Unangst wrote:
>
> > Oh, right, I reworded it slightly, but I think th
This looks okay to me.
(plus two months ping)
‐‐‐ Original Message ‐‐‐
On Tuesday, April 16, 2019 8:19 PM, Ted Unangst wrote:
> Oh, right, I reworded it slightly, but I think this is something we should
> note.
>
> Index: fsync.2
>
> =
Oh, right, I reworded it slightly, but I think this is something we should
note.
Index: fsync.2
===
RCS file: /home/cvs/src/lib/libc/sys/fsync.2,v
retrieving revision 1.14
diff -u -p -r1.14 fsync.2
--- fsync.2 10 Sep 2015 17:55:2
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Saturday, February 16, 2019 7:40 AM, Maximilian Lorlacks
wrote:
> ‐‐‐ Original Message ‐‐‐
> On Thursday, January 31, 2019 11:31 PM, Alexander Bluhm
> alexander.bl...@gmx.net wrote:
>
> > On Thu, Jan 31, 2019 at
On Sat, Feb 16, 2019 at 07:40:42AM +, Maximilian Lorlacks wrote:
> People may object to errors being lost when the vnode is released,
> as that would lose errors in a scenario like write -> close -> open
> -> fsync.
Is there any guarantee an application will be operating on the same
underlying
On Saturday, February 16, 2019, Abel Abraham Camarillo Ojeda <
acam...@verlet.org> wrote:
>
>
> On Saturday, February 16, 2019, Maximilian Lorlacks <
> maxlor...@protonmail.com> wrote:
>
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Thursday, January 31, 2019 11:31 PM, Alexander Bluhm <
>> alexande
On Saturday, February 16, 2019, Maximilian Lorlacks <
maxlor...@protonmail.com> wrote:
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, January 31, 2019 11:31 PM, Alexander Bluhm <
> alexander.bl...@gmx.net> wrote:
>
> > On Thu, Jan 31, 2019 at 04:26:45PM -0500, Ted Unangst wrote:
> >
> > > Ins
‐‐‐ Original Message ‐‐‐
On Thursday, January 31, 2019 11:31 PM, Alexander Bluhm
wrote:
> On Thu, Jan 31, 2019 at 04:26:45PM -0500, Ted Unangst wrote:
>
> > Instead, we note that the write failed and mark a flag in the vnode. Future
> > calls to fsync will then return EIO when this fla
On Thu, Jan 31, 2019 at 04:26:45PM -0500, Ted Unangst wrote:
> Instead, we note that the write failed and mark a flag in the vnode. Future
> calls to fsync will then return EIO when this flag is set. We clear the flag
> when the vnode is released.
Sounds reasonable.
OK bluhm@
> Index: kern/vfs_b
Ted Unangst wrote:
> > Keeping a buf with an error in the delayed write list would probably have
> > some
> > serious consequences. When would we ever remove it?
>
> Thought about this some more. The best approach may be to set a flag in
> the vnode that there was an IO error, and return that for
Ted Unangst wrote:
> Maximilian Lorlacks wrote:
> > Good day,
> >
> > It seems that fsync(2) may data after returning EIO once[1]. This
> > behaviour seems to cause problems with databases such as PostgreSQL
> > and goes contrary to the man page's description, which says that
> > "fsync() and fda
Maximilian Lorlacks wrote:
> Good day,
>
> It seems that fsync(2) may data after returning EIO once[1]. This
> behaviour seems to cause problems with databases such as PostgreSQL
> and goes contrary to the man page's description, which says that
> "fsync() and fdatasync() should be used by progra
Good day,
It seems that fsync(2) may data after returning EIO once[1]. This
behaviour seems to cause problems with databases such as PostgreSQL
and goes contrary to the man page's description, which says that
"fsync() and fdatasync() should be used by programs that require a
file to be in a known
13 matches
Mail list logo
