On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote: > On Tuesday 27 February 2007 15:53, Alex Kozlov wrote: > = > Yes, I switched to swap-backed md already. But the malloc-based variety > is > = > currently the _default_ (see /etc/defaults/rc.conf)... > = Bad default. > > Filing a PR.
Keep in mind that changing the default can break existing setups. Such setups are likely to be broken anyway, but... E.g., if we drop the -M flag, it will break systems with tons of RAM but little swap using tmpmfs. OTOH, if we add '-o reserve', that will break systems with a too large but mostly unused tmpmfs. A sort of a loud announcement will be needed. By the way, I seem to be the one responsible for the paragraph in rc.conf(5) advocating -M "for maximum performance and system stability at low memory conditions". When I wrote it, I thought as follows: were the system low on memory, additional swap activity due to mfs would just make the system start thrashing sooner, while malloc'd mfs would just report ENOSPC. I was unaware of the panic back then. Perhaps it was a misconception, either. I haven't heard of any real pitfalls in swap-backed mfs, and getting ENOSPC on /tmp early is no good. > = > Creation of a 2Gb malloc-based md should've failed on a machine with > = > 768Mb of RAM, shouldn't it have? > = Only if you set '-o reserve'. Memory for malloc-based md was allocated > = dynamically. > > But malloc can only allocate from RAM, right? So the amount of RAM is the > hard > limit, which a malloc-based md can not exceed even in theory. This means, > md-creation should've failed... > > In fact, the limit should, of course, be even lower -- and mdmfs should be > smart enough to substract the sizes of other kernel memory chunks from the > maximum. > > Since even that would still not be a guarantee against running out, the > system > should be able to recover gracefully instead of panicing. Do you agree? FWIW, some discussion of the panic is in the audit trail of kern/87255. Irrespective of tmpmfs defaults, this is a way to panic the system with stock tools and without doing something totally stupid like writing junk to /dev/mem. -- Yar _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
