From: Matthias Andree (no email)
Date: Fri Aug 01 2003 - 13:57:03 EDT
(Wietse Venema) writes:
>> I think using cscope to figure the full list of rename() and link() is
>> safe enough, ultimately, there'd be one function sync_rename() and one
>> sync_link() and these functions would be the only ones that call
>> rename() or link().
>
> 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. So what's the reason to
refuse it?
In fact, Postfix does not call link() today, but it calls the
sane_link() wrapper to work around non-idempotence of the wire methods
NFS offers. rename is called from four places:
0 fsstone.c rename_file 66 if (rename(old_path, new_path))
1 remove.c REMOVE 69 return (rename(path, vstring_str(dest)));
2 postconf.c edit_parameters 472 if (rename(temp, path) < 0)
3 sane_rename.c sane_rename 49 if (rename(from, to) >= 0)
again, you see almost everything goes through sane_rename.
I think this is the right place to enforce Linux or Softupdates
semantics. For people running Postfix on traditional UFS/FFS, you could
offer a compile-time -DTRADITIONAL_FS_SEMANTICS option that switches
these performance hogs off. Given that most free file Unices are
shipping or planning to ship file systems that do these directory
operations asynchronously, something like this will become more
important for non-Linux systems as well.
Again, the major problem I see with that is the non-visibility of the
implications. If you install a FreeBSD today, your /usr and /var will be
softupdates, that comprises user home directories and the queue.
The choice of systems offering traditional BSD semantics in their
default install is steadily decreasing. If we need Postfix to be safe on
such systems, we'll have to deal with that. Linux ext3fs in some
versions offers an -o dirsync option which is what's needed for Postfix,
but we'll have to reiterate all this stuff with Linux 2.6 again, which
file systems implement -o sync, which do the quicker -o dirsync, which
accept bug ignore this option, when is fd_a = open(a,, ...) link(a, b)
fsync(fd_a) close(fd_a) sufficient and all that.
Given the recent XFS replies, XFS/ext3fs/reiserfs3.6 on Linux 2.4 are safe
when the code is softupdates safe, i. e. does fsync() on any file in the
same file system after a link or rename.
Looking at postfix-2.0.14-20030717: fixing sane_link fixes maildir.c
implicitly. Is there another reason that you base your objection on?
-- Matthias Andree
|
|
|