chris@umcp-cs.UUCP (Chris Torek) (08/20/86)
>In article <244@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >>This [immediate physical I/O for, e.g., directory writes] is an >>unfortunate side effect of the file system reliability enhancements >>that were done for System V (III?). In article <792@ho95e.UUCP> wcs@ho95e.UUCP (Bill Stewart 1-201-949-0705 ihnp4!ho95c!wcs HO 2G202) asks: >Is there any way to tell the system "Don't bother syncing /tmp"? It would be relatively easy to add to the 4.2/4.3BSD file system a parameter marking any particular file system as `unreliable', and, based on this, to use delayed writes for all FS operations. We like reliable /tmp files here, since editor temporaries are stored there; but after about the fifth full file system restore, I have been considering at least adding a global flag (set via `adb -w' on the running kernel) to disable synchronous writes entirely. If the restore dies for some reason, I am going to restart the whole thing anyway: so I care not if what I have after the crash is unsalvageable. Restores are infrequent enough that any serious work to speed them is not worthwhile, but one global flag would be trivial. . . . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
hutch@sdcsvax.UUCP (Jim Hutchison) (08/23/86)
<>
Back to ram disks, why bother to cache blocks from a ram disk? Seems
like a very big waste. If it was somehow possible to make all the
writes to a named fs physical (hack the strategy??), then you could
have a /tmp that ran fast, and did not impair the buffer cache nor
*Get synced*. You certainly would not want to have editor files in
that fs (could use /usr/tmp instead), but for fast access temporary
files it could be a win overall.
--
Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch
ARPA: Hutch@sdcsvax.ucsd.edu
"The fog crept in on little cats feet" -CS