Xref: utzoo comp.unix.questions:14680 comp.unix.wizards:17126 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!iuvax!uxc.cso.uiuc.edu!tank!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.unix.questions,comp.unix.wizards Subject: Re: Fine grained sync policy control (was: What I want in GNU OS) Message-ID: <18410@mimsy.UUCP> Date: 5 Jul 89 23:38:36 GMT References: Followup-To: comp.unix.questions Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 50 In article cline@suntan.ece.clarkson.edu (Marshall Cline) posts one copy, each separate, to comp.unix.questions and comp.unix.wizards, of the following. I have redirected followups to comp.unix.questions only. >... I propose the following _mechanism_ (system calls) could be added >to facilitate the _policy_. ... >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. There is now no system call that deals with `blocks' rather than `bytes', and I believe this should be maintained. (Actually, on 4.3BSD and similar, `stat' fills in an st_blocks variable, but this is in addition to the st_size field.) In any case, I am not sure why one would care how many bytes or blocks were not yet written: the only interesting question seems to be `any' versus `none', with the object of changing `any' into `none' if necessary. >int sync_fd(int fd, int wait_until_done); >/* Causes precisely one file to be "sync()"ed (see sync(3)). [there is no sync(3); perhaps you mean sync(2)] > * This gives users the fine-grained control over which files they > * consider critical in the event of a system crash. 4BSD already has `fsync', which ... causes all modified data and attributes of /fd/ to be moved to a permanent storage device. This normally results in all in-core modified copies of buffers for the associated file to be written to a disk. /Fsync/ should be used by programs that require a file to be in a known state, for example, in building a simple transaction facility. (/x/ represents italics). The only difference here is that you are forced to wait (fsync uses bwrite, not bawrite). >typedef enum {DELAYED_WRITE, IMMEDIATE_WRITE, BAD_POLICY} sync_t; > >sync_t update_policy(int fd, sync_t mechanism); SysV has an open() flag that causes writes to be immediate. Presumably this can also be set and cleared with fcntl(F_SETFL). 4BSD might acquire this someday as well (it is not hard to implement). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris