lkml.org 
[lkml]   [1999]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:1.865 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site