mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (06/28/90)
In article <691@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes: >A really simple solution would be to make /tmp a seperate partition and turn >of sync writes. That's what I have done in the latest USENIX paper. >A mkfs (or newfs) takes of the order of the same time as >an fsck anyway. /tmp is usually cleared on a reboot so there is no problem. Do you know ex3.7preserve? We should try fsck and fsck -y before newfs. Masataka Ohta
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (06/28/90)
In article <MOSS.90Jun27085023@ibis.cs.umass.edu> moss@cs.umass.edu writes: > In general computation, it might be true. > In case of temporary compiler output files, > isn't it enough just try to "make" again? > If something wrong, let's try "make clean" and "make". > > Or did I miss some other important points? >The problem is that the file system structure itself (inodes, free block info, >etc.) can get somewhat scrambled, such that it is not even a legal file system >structure. In general, it is a problem. But, in some cases, it is not a problem. Masataka Ohta
casey@gauss.llnl.gov (Casey Leedom) (06/29/90)
| From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta) | | >From: ian@sibyl.OZ (Ian Dall) | > | >A mkfs (or newfs) takes of the order of the same time as | >an fsck anyway. /tmp is usually cleared on a reboot so there is no problem. | | Do you know ex3.7preserve? We should try fsck and fsck -y before newfs. No longer relevant. Under the new directory organization /tmp is supposed to be used for truly transient files like compiler temporaries, etc. /usr/tmp is supposed to be used for more important files like editor temporaries, etc. Berkeley has already implemented a Memory File System and mount /tmp on it by default.
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (07/03/90)
In article <63090@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes: >| Do you know ex3.7preserve? We should try fsck and fsck -y before newfs. > No longer relevant. Under the new directory organization /tmp is supposed >to be used for truly transient files like compiler temporaries, etc. /usr/tmp >is supposed to be used for more important files like editor temporaries, etc. That is a good news also to me. >Berkeley has already implemented a Memory File System and mount /tmp on it by >default. Memory disk (even virtual memory disk) has several fundamental defects. Judging from the previous USENIX, Berkley's memory disk inherites the property that sometimes: Real disk faster than RAM disk which was the original subject: Why do you use memory disk if it is slower then real disk? Masataka Ohta
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (07/05/90)
In article <103@array.UUCP> colin@array.UUCP (Colin Plumb) writes: >>Trying to solve this problem in the manner described in Ohta's Usenix paper >>is a mistake. It's an inapproriate solution to the problem. >I think it's a wierd hybrid of a ramdisk and stable storage, and I >think it's ugly, but I can't say it's *wrong*. It is an interesting point of view to see UNIX buffer cache mechanism a wierd bybrid of a ramdisk and stable storage. As I added almost nothing and just used an existing mechanism, you are offending UNIX buffer chache mechanism itself. You may think buffer cache is ugly, but to me, it is just fine. Masataka Ohta
colin@array.UUCP (Colin Plumb) (07/08/90)
>In article <103@array.UUCP> colin@array.UUCP (Colin Plumb) writes: >>I think it's a wierd hybrid of a ramdisk and stable storage, and I >>think it's ugly, but I can't say it's *wrong*. In article <5784@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >It is an interesting point of view to see UNIX buffer cache mechanism >a wierd bybrid of a ramdisk and stable storage. Oops... damn, we expire news too fast around here. I'd like to apologise for getting Masataka Ohta's scheme mixed up with another one I heard about that also worked, but was (in my opinion) less than elegant. For some reason, I made the wrong connection in my head, only to have it blown when he reminded me of what he really did. I apologise for the comment, and offer my admiration for having achieved so much gain for so little additional complexity. -- -Colin
shekita@provolone.cs.wisc.edu (E Shekita) (07/09/90)
|Masataka Ohta writes: ||It is an interesting point of view to see UNIX buffer cache mechanism ||a wierd bybrid of a ramdisk and stable storage. | |Oops... damn, we expire news too fast around here. I'd like to |apologise for getting Masataka Ohta's scheme mixed up with another one |I heard about that also worked, but was (in my opinion) less than |elegant... Anyone care to enlighten us about Ohta's scheme (without just pointing to a ref)? I've seen it mentioned in this thread a number of times now without any description and I'm curious how it works. I'm sure there are others in the same boat as me. Gene
guy@auspex.auspex.com (Guy Harris) (07/24/90)
>Anyone care to enlighten us about Ohta's scheme (without just >pointing to a ref)? I've seen it mentioned in this thread a number of >times now without any description and I'm curious how it works. From the paper, it works by having a mount option that undoes the "ordered write" changes done by, say, Berkeley, to make sure that the file system's data structures on disk aren't in a seriously inconsistent state at any time. Thus, *all* file system writes can be delayed (write-behind), including writes to directories and inodes. The idea is that you do this on file systems the survival of whose contents you don't care all that much about, e.g. "/tmp". The same rationale is used for, say, Berkeley's "virtual memory disk" and Sun's "virtual memory file system" in 4.1.
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (07/24/90)
It's interesting to note that you get a similar effect when using a
cached write-back disk controller. The kernel does the write neatly
ordered and controller reorders on position for i/o. It's not obvious to
sysadmins who install something like this that the performance gain
comes with a (slight) increase in the chance of a blown f/s on power
fail. Note that a software crash doesn't hurt the controller, so all
data will be written anyway.
The performance gains available by doing this are great, particularly
on systems with light load, since the cpu is often not the bottleneck.
Consider this system, used for mail and news:
________________________________________________________________
CPU in seconds
cpu[IDLE] = 487647 ( 94.7%) wait[IO] = 8931
cpu[USER] = 8143 ( 1.6%) wait[SWAP] = 0
cpu[KERNEL] = 19299 ( 3.7%) wait[PIO] = 0
I/O counts
bread = 286531 bwrite = 377804
lread = 8876796 lwrite = 3090676
readch = 1044977964 writech = 649909542
Process counts
swapin = 0 swapout = 0
pswitch = 5154173
syscall = 29242599 sysfork = 68658
________________________________________________________________
Although the lack of swap indicates enough memory, I would really want
to have more before I dedicated any to ramdisk, but I suspect that just
making /tmp a ramdisk of about 8MB would help performance a lot.
--
bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"Stupidity, like virtue, is its own reward" -me