Messages in this thread | | | Date | Tue, 28 Dec 1999 12:29:30 -0800 (PST) | From | Tigran Aivazian <> | Subject | Re: [PATCH] 2.3.34/pre-2.3.35-3 ramdisk/initrd NOT as a |
| |
On Tue, 28 Dec 1999, Khimenko Victor wrote: > TA> A human being should just be able to tell the system "make me a ramdisk of > TA> size 64M with ext2 filesystem on it". > > And system will try it's best to satisfy such request. You can ask system > to create 10GiB filesystem on 1GiB HDD (with FAT you can do such thing > easily :-) and you'll get random oopses later as well. Why it's Ok for > "normal" device and not Ok for ramdisk ? FAT is abnormal filesystem, even when created on a normal device :)
> 2) It does not the case with normal memory allocation in Linux. Why Ramdisk > should be different ? it does bother me in that area as well. I am not sugegsting that Linux should behave like SVR4 or SVR5 in that aspect but if it chooses the way of, e.g. AIX it should be at least as tolerant - AIX's "oom" situation is less wilde than Linux's. However, I would be happy if it was configurable - CONFIG_SWAP_ALLOC_POLICY = "Linux traditional" or "SVR4 foolproof"
(I bet some "smart ass" will tell me it is already possible with some weird combination of /proc/sys/ sysctl :) I love "smart ass"-es )
> So far I can not understood why it should be fixed. At least I can not > understood why "normal OOM" (in case of OOM linux goes REALLY wild and will > kill random processes including syslog (almost always) and init (sometimes) > and this problem is there for years) does not bother you more then randisk > overflow case. To me situation where system can be killed with stupid runaway > process with memory leak or wild fork is MUCH worse then situation where you > created ramdisk more then there are physical RAM and then system was locked... > At least in second case you made something STUPID from ROOT... >
yes, I agree with your last paragraph. Fortunately, there are still plenty of things where Linux can (and should) be improved :)
Regards, Tigran.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |