Re: ext3-2.4-0.9.4

[Bill Rugolsky Jr.]

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