Fine grained sync policy control (was: What I want in GNU OS)

[Marshall Cline]

Craig Jackson (drilex!dricej at bbn.com, drilex!dricejb at bbn.com) and
I (Marshall Cline, cline at sun.soe.clarkson.edu) have been having an
email discussion, some of the results of which I'd like to post.

The gist is a set of new system calls which allow "sync()" to occur on a
file-by-file basis.  Right now "update()" sync's the entire filesystem
occasionally.  But _some_ file (and only the user knows which) might need
to be kept up-to-date more often to avoid disaster in the event of a system
crash....

In article <CLINE.89Jun22135208 at suntan.ece.clarkson.edu> M.Cline writes:
>   ...One of the philosophical issues upon which Un*x
>is built is the separation of policy and mechanism.  The kernel takes
>care of mechanism, with as little policy as possible.  (No one would
>claim Un*x does a perfect at this separation, but it tries)....
>   Avoiding delayed-write would, in general, bring performance down
>pretty badly.  Given an OS that _does_ have delayed-write, the only
>question is: how often should we "sync" the system?  Personally, I
>think this _policy_ decision should be left _OUT_ of the kernel.

dricejb at drilex.UUCP (Craig Jackson) replies:
>Many Unixes do not offer me my policy preferences: force all directory writes,
>and *certain* file writes, directly to the disk.  When forcing a file write,
>tell me when all previously-written data has actually reached the disk,
>so I can proceed with other writes.

I thought that sounded like a "neat enough" idea to post it and get other
ideas (and undoubtedly a few flames :-).  I propose the following _mechanism_
(system calls) could be added to facilitate the _policy_.  The default
situation (on file descriptors which haven't been changed via one of these
system calls) could be equivalent to the current delayed-write-and-
update-occasionally method.

__________________________ NEW SYSTEM CALLS ___________________________

int num_dirty_blocks(int fd);
/* "fd" is the file descriptor of an open file.
 * Returns the number of dirty blocks associated with the file descriptor.
 * If "update_policy()" has been set to IMMEDIATE_WRITE, always returns 0.
 * Returns -1 on error (and sets errno, blah, blah, blah).
 */

int sync_fd(int fd, int wait_until_done);
/* Causes precisely one file to be "sync()"ed (see sync(3)).
 * This gives users the fine-grained control over which files they
 * consider critical in the event of a system crash.
 * Thus the policy is in the hands of the users, not the kernel.
 * If "wait_until_done" is non-zero, and if the "fd" has any dirty
 * blocks (see "num_dirty_blocks()"), the calling process is blocked
 * until all dirty blocks of the "fd" are successfully written to disk.
 * Returns 0 on success, -1 on error (and sets errno, blah, blah, blah).
 */

typedef enum {DELAYED_WRITE, IMMEDIATE_WRITE, BAD_POLICY} sync_t;

sync_t update_policy(int fd, sync_t mechanism);
/* "fd" is the file descriptor of an open file.
 * This directs the kernel regarding the desired update policy for "fd".
 * If "mechanism" is DELAYED_WRITE, doesn't write dirty data blocks until
 * a "sync()" or a "sync_fd()" call (which might happen due to "update(8)").
 * If "mechanism" is IMMEDIATE_WRITE, any changed blocks are immediately
 * written to disk.  This option should be used only on files where the
 * file's data is critical with respect to a system crash.
 * Returns the update_policy that formerly was associated with the file.
 * If "fd" is not an open file descriptor, or if "mechanism" isn't one of
 * the above values, no action is performed, and BAD_POLICY is returned.
 */


The end result would of course be that you could, on a file-by-file basis,
specify what needs to be kept consistent.  Those files which ABSOLUTELY
MUST be CONTINUALLY preserved intact could have their update policy set to
IMMEDIATE_WRITE.  Those files which OCCASIONALLY need to have their contents
"flushed" to disk could use "sync_fd()", similarly to the way one fflushes
stdout so incomplete lines appear on the screen.

Anyway, the point is this: Keep the policy out of the kernel.
Any thoughts?

Marshall
--
	________________________________________________________________
	Marshall P. Cline	ARPA:	cline at sun.soe.clarkson.edu
	ECE Department		UseNet:	uunet!sun.soe.clarkson.edu!cline
	Clarkson University	BitNet:	BH0W at CLUTX
	Potsdam, NY  13676	AT&T:	315-268-6591