Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!cs.utexas.edu!uunet!image.soe.clarkson.edu!news From: cline@suntan.ece.clarkson.edu (Marshall Cline) Newsgroups: comp.unix.wizards Subject: Fine grained sync policy control (was: What I want in GNU OS) Message-ID: Date: 30 Jun 89 21:03:06 GMT Sender: news@sun.soe.clarkson.edu Reply-To: cline@sun.soe.clarkson.edu (Marshall Cline) Organization: Clarkson University, Postdam NY Lines: 87 Craig Jackson (drilex!dricej@bbn.com, drilex!dricejb@bbn.com) and I (Marshall Cline, cline@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 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@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@sun.soe.clarkson.edu ECE Department UseNet: uunet!sun.soe.clarkson.edu!cline Clarkson University BitNet: BH0W@CLUTX Potsdam, NY 13676 AT&T: 315-268-6591