From: Wietse Venema (no email)
Date: Fri Aug 01 2003 - 18:38:19 EDT
Matthias Andree:
> On Fri, 01 Aug 2003, Wietse Venema wrote:
>
> > > > This is not robust. Postfix will change and there is no guarantee
> > > > that today's cscope result will be valid tomorrow.
> > >
> > > Of course not. There is no guarantee that tomorrow's Postfix doesn't
> > > contain sprintf rather than vsprintf either.
> >
> > I will not reply to such a silly suggestion.
>
> I don't see much of a difference there. These functions are supposed to
> suppress errors. One error is the non-idempotence of NFS method, the
> other is non-synchronicity of some local file system method.
The sane_XXX() routines merely ignore errors selectively, while
the sync_XXX() routines actually add extra operations in order to
force data to stable storage before the call returns (on systems
where this isn't done automatically).
Not every sane_XXX() operation in Postfix needs the baggage of
sync_XXX().
You're welcome to contribute sync_{mkdir/link/rename}() routines,
but it will be a lot of fun to:
- Always run an appropriate proper errno (we don't need another
ENOENT after write(2) fiasco).
- Have code that actually works. With Linux, you can open() and
fsync() a directory in a local file system. That already breaks
when the file is mounted from an NFS server, and there is no
guarantee that fsync() will be the right tools with other file
systems.
By the way, NFS requires that stable storage is updated before the
server replies to a client update request. How does a LINUX NFS
server get away with this?
If NFS is done properly, there is no need for a client to mount
file systems synchronously. The client might have to turn off
attribute caching, though.
Wietse
|
|
|