Xref: utzoo comp.unix.wizards:8327 comp.os.misc:432 Path: utzoo!mnetor!uunet!husc6!mailrus!ames!pacbell!rtech!llama!daveb From: daveb@llama.rtech.UUCP (It takes a clear mind to make it) Newsgroups: comp.unix.wizards,comp.os.misc Subject: Re: Uses for access time, stuff in inodes Message-ID: <2065@rtech.UUCP> Date: 7 May 88 21:35:49 GMT References: <2059@rtech.UUCP> <3672@lynx.UUCP> <10613@steinmetz.ge.com> <577@minya.UUCP> <12606@tut.cis.ohio-state.edu> Sender: news@rtech.UUCP Reply-To: daveb@llama.UUCP (It takes a clear mind to make it) Organization: Relational Technology, Inc. Alameda, CA Lines: 35 In article <12606@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >daveb@llama.rtech.UUCP says... > It would be nice if there were some way for > O_SYNCed files to avoid [2 writes/call]: maybe just defer the > access/mod time write until the file is closed. > >I would disagree. If data blocks are updated but the inode is left >in-core-only, what value have I gained by using O_SYNC? If the system >crashes right now, with half a megabyte of data written, but no record >of the changes to the inode yet out to disc, O_SYNC has become >useless. > >I tend to think that O_SYNC is specifically intended for those folks >who are explicitly willing to put up with the performance hit of 2 >physical writes/call. OK, then you write the inode when the file size changes, and update the mod/access time at close. Maybe you have O_SYNC work this way if an additional (or alternative) option, say O_FASTSYNC was provided. The specific example we have in mind is this. There is a 1M file lying around, within which we are doing seeks and read and writes to perform updates (as you might imagine this is DBMS activity). We don't give a hoot about the access/mod time on the file, but we care a lot that the data actually makes it to the disk. That extra disk i/o can cut your throughput in half, which is not acceptable. It would also be perfectly acceptable to have an additional system call that explicitly said, "I am extending this file to this length, get the pages and write the inode to disk." To a certain extent, this would be a generalization of th existing BSD ftruncate call. -dB {amdahl, cpsc6a, mtxinu, ptsfa, sun, hoptoad}!rtech!daveb daveb@rtech.uucp