Re: ext3-2.4-0.9.4

Bill Rugolsky Jr.
2001-08-03T17:06:42Z

On Fri, Aug 03, 2001 at 05:25:09PM +0200, Daniel Phillips wrote:
> As I read the (excerpts from the) SUS, this isn't required, only that
> at least one namespace path from the root to the fsynced file is
> preserved. I can imagine an efficient implementation for this.

I might be way off base here; if so tell me.
Let's litter some sample code with fsync():

fd = open("tmp/x",O_CREAT|O_WRONLY);
...
fsync(fd);
rename("tmp/x","spool/x");
fsync(fd);
close(fd);

This looks safe and correct, given your semantics. It is, unless the
link count of that file rises above 1, from say a mail admin quite
reasonably doing

ln tmp/x peek/x

in the interval specified by "...". In that case, it's not required
that "tmp/x" or "spool/x" ever hit disk. So the code is only correct
if the file only has a single link, or we specify ordered meta-data
updates for open/rename/link/... Following Stephen's argument, is
"peek/x" any better than "lost+found"? With more than one admin?

On older non-BSD systems (SYS3?,SYSV 3.x?) that don't do rename(), files can't
be moved without bumping their link counts:

fd = open("tmp/x",O_CREAT|O_WRONLY);
...
fsync(fd);
link("tmp/x","spool/x");
fsync(fd); /* <- possibly a NOP with your semantics */
unlink("tmp/x");
fsync(fd);
close(fd);

Again, this will fail to preserve your desired semantics on crash,
unless we have ordered meta-data updates, or the stronger synchronous
link() requirement.

I think the semantics that you propose might be marginally useful, but
I don't think SUS requires it; my understanding (and that of a
close friend and former POSIX reviewer) has always been that inodes are
distinct from directory entries, and that fsync() preserves the fields
that stat() returns: mode, uid, gid, size, {a,c,m}time.

Regards,

Bill Rugolsky