Re: [PATCH] 2.4.8-pre3 fsync entire path (+reiserfs fsync semantic change patch)

Jan Harkes (jaharkes@cs.cmu.edu)
Sat, 4 Aug 2001 13:35:00 -0400


On Sat, Aug 04, 2001 at 10:01:43AM +1200, Chris Wedgwood wrote:
> On Fri, Aug 03, 2001 at 06:34:14PM +0000, Linus Torvalds wrote:
>
> fsync(int fd)
> {
> dentry = fdget(fd);
> do_fsync(dentry);
> for (;;) {
> tmp = dentry;
> dentry = dentry->d_parent;
> if (dentry == tmp)
> break;
> do_fdatasync(dentry);
> }
> }
>
> I really like this idea. Can people please try out the attached patch?

Deadly for Coda, every fsync triggers an upcall to userspace, which
costs at least 2 context switches and a whole bunch of network traffic
as updates are sent back to the server, i.e. the fact that some parent
has a new child or timestamp is not related to or interesting for this
delivery.

The existing fsync(dir) is far better and the reasons are simple and
explained multiple times throughout this far too long thread. So let me
reiterate.

- fsync(dir) is an _explicit_ indication by an application that actually
cares what precisely needs to be written to disk.
- fsync(dir) doesn't negatively affect applications that don't care.
- The proposed patch doesn't solve the 'oops I relinked the file, or I
renamed a parent' problems where the path leading to a file is lost
anyways. And the relinking is exactly what is done by both qmail and
cyrus imap, i.e. this patch wouldn't even solve the problem that is
being discussed.
- fsync(dir) doesn't write out anymore that has to be written, i.e. a
open/unlink in a temporary directory doesn't need to hit the disk if
there is an fsync in the middle (see qmail/cyrus syscall paths in a
previous email)
- We don't need to modify the code to make fsync(dir) work! If it turns
out to be too slow, let's fix fsync(dir) to be more efficient.

Jan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/