From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dan Cross <cross@math.psu.edu>
Message-Id: <200102080119.UAA03525@augusta.math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 9p2k, fsync
In-Reply-To: <20010207152343.C1B91199E1@mail.cse.psu.edu>
Cc:
Date: Wed,  7 Feb 2001 20:19:30 -0500
Topicbox-Message-UUID: 5cc48dc0-eac9-11e9-9e20-41e7f4b1d025

In article <20010207152343.C1B91199E1@mail.cse.psu.edu> you write:
>Fsync etc. is at the wrong level.  The issue is not a system-wide
>question, but a file-server question.  As a trivial example of how
>to think about this problem,
>	disk/kfscmd sync
>strikes closer to the way the problem should be handled than
>a 'sync' system call.  The details of how a file server backs up
>and stabilizes its storage are specific to the server, and should
>be implemented by it.  Plan 9 conventions show how to provide
>such an interface; the file protocol is not the place.

Hey?  No disagreement that it's a fileserver issue, but I should also
be able to ask the file server to sync the data associated with a
particular FID.

Multics had this problem; no synchronization primitives for segments.
It was impossible to build a database on it for many years (maybe they
fixed it eventually; I don't know), because one couldn't guarantee
serialization of transactions on persistent media.  It would be a shame
to send Plan 9 down the same road for the exact same reason.

	- Dan C.