Subject: Re: Removing tmpfs' experimental status
To: None <firstname.lastname@example.org>
From: Elad Efrat <elad@NetBSD.org>
Date: 10/22/2006 20:30:54
Thor Lancelot Simon wrote:
> On Sun, Oct 22, 2006 at 06:37:42PM +0200, Tobias Nygren wrote:
>> If you put pkgsrc's wrkobjdir on a tmpfs filesystem, like for example ...
>> .. and then try to make install in pkgsrc/devel/autoconf, it will fail with
>> the output below. This does not occur when wrkobjdir is on an ffs
>> filesystem. I've reproduced this on i386 and alpha.
> And I have reproduced it on amd64. When I looked at the autoconf tests
> that failed, they had clearly been corrupted in memory. This is why I
> don't use tmpfs on any of my systems: I may only _notice immediately_ when
> data corruption causes autoconf to fail, but that doesn't mean that other
> data isn't being corrupted!
> Not good.
Yes, so I guess it stays experimental. :)
On a different note, somewhat off-topic, I'm going to enable by default
both fileassoc(9) and veriexec(9) in GENERIC. Reasons being that unless
Veriexec is actually *used* it doesn't hurt to have it there, and having
it enabled by default makes them more accessible.
Here are differences in kernel sizes. Base kernel is GENERIC with
text data bss dec hex filename
8042325 332064 434008 8808397 8667cd base
8045261 332064 434072 8811397 867385 base+fileassoc
8056685 332096 434136 8822917 86a085 base+fileassoc+veriexec
Are there any objections for this?