On Wed, Aug 17, 2016 at 10:20:40PM +0200, Jilles Tjoelker wrote:
> On Mon, Aug 15, 2016 at 07:08:51PM +0000, Konstantin Belousov wrote:
> > /* ISO/IEC 9945-1: 1996 */
> > #if __POSIX_VISIBLE >= 199506 || __XSI_VISIBLE
> > int fsync(int);
> > +int fdatasync(int);
> >
> > /*
> > * ftruncate() was in the POSIX Realtime Extension (it's used for shared
>
> Apparently these functions were added closely enough in time that they
> can stay together here :)
Is this a form of suggestion to use other value for POSIX_VISIBLE ?
> > +#if 0
> > + if (!fullsync)
> > + /* XXXKIB: compete outstanding aio writes */;
>
> Under the _POSIX_SYNCHRONIZED_IO option, completing outstanding I/O
> requests is in fact required for fsync() as well. The fdatasync()
> function is completely under the _POSIX_SYNCHRONIZED_IO option.
>
> We do not implement this option, but keeping fdatasync()'s guarantees a
> subset of fsync()'s guarantees seems sensible.
I will consider this if and when the AIO flush would be implemented.
I looked at the AIO code to estimate the needed work, but did not started
coding and quite possible it would be postponed.
> > +%% fdatasync vp L L L
> > +
> > +vop_fdatasync {
> > + IN struct vnode *vp;
> > + IN struct thread *td;
> > +};
> A waitfor parameter like in vop_fsync may be useful to implement
> aio_fsync(O_DSYNC) later on.
I really do not see how would it be. aio_fsync(O_DSYNC) is equivalent
to fdatasync(2) in the async context. Completion of the aio request
indicates that virtual fdatasync(2) execution did finished in that
context. The use of waitfor in the VOP_FSYNC() is to allow syncer
to initiate flush without waiting, or getting notification for the
completion.
Could you, please, elaborate ? If the KPI change is needed there, it
is obviously desirable to make it right before MFC to stable.
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
