On Thu, 2010-10-07 at 17:36 +0200, Stefan Esser wrote:
> Am 07.10.2010 05:29, schrieb Devin Teske:
> >
> > On Oct 6, 2010, at 4:09 PM, Brandon Gooch wrote:
> >
> >> On Wed, Oct 6, 2010 at 3:45 PM, Devin Teske wrote:
> >>> Hello fellow freebsd-hackers,
> >>>
> >>> Long-time hacker, first-time pos
On Thu, Oct 7, 2010 at 11:45 AM, Jaakko Heinonen wrote:
> On 2010-10-06, Alexander Best wrote:
>> $ sudo rm -d /tmp/chflags.XX
>> $ tmpfile=`mktemp /tmp/chflags.XX`
>> $ sudo chflags arch $tmpfile
>> $ chflags noarch $tmpfile
>>
>> is what's causing the problem. the last chflags call shoul
On Thu, Oct 7, 2010 at 12:43 PM, Sergey Kandaurov wrote:
> On 7 October 2010 22:45, Jaakko Heinonen wrote:
>> On 2010-10-06, Alexander Best wrote:
>>> $ sudo rm -d /tmp/chflags.XX
>>> $ tmpfile=`mktemp /tmp/chflags.XX`
>>> $ sudo chflags arch $tmpfile
>>> $ chflags noarch $tmpfile
>>>
>>>
On 7 October 2010 22:45, Jaakko Heinonen wrote:
> On 2010-10-06, Alexander Best wrote:
>> $ sudo rm -d /tmp/chflags.XX
>> $ tmpfile=`mktemp /tmp/chflags.XX`
>> $ sudo chflags arch $tmpfile
>> $ chflags noarch $tmpfile
>>
>> is what's causing the problem. the last chflags call should fail,
On 2010-10-06, Alexander Best wrote:
> $ sudo rm -d /tmp/chflags.XX
> $ tmpfile=`mktemp /tmp/chflags.XX`
> $ sudo chflags arch $tmpfile
> $ chflags noarch $tmpfile
>
> is what's causing the problem. the last chflags call should fail, but it
> doesn't.
Here is a patch for UFS:
%%%
Index:
on 05/10/2010 18:27 Andriy Gapon said the following:
> Here's an updated patch:
> http://people.freebsd.org/~avg/sysctl-kmem_map_size2.diff
> The new code wraps kmem_map->size into SYSCTL_PROC() to handle vm_size_t type
> differences for different platforms. The idea is suggested by Ed Maste.
So
Here is patch that applies the technique from panic() to generic_stop_cpus() to
prevent its parallel execution on multiple CPUs:
http://people.freebsd.org/~avg/generic_stop_cpus.diff
In theory this could lead to two CPUs stopping each other and everyone else, and
thus a total system halt.
Also,
panic_cpu variable in kern_shutdown.c should be volatile otherwise it's cached
in
a register in the innermost while-loop in this code (observed on amd64 with base
gcc and -O2):
if (panic_cpu != PCPU_GET(cpuid))
while (atomic_cmpset_int(&panic_cpu, NOCPU,
PCPU_GET(cpuid)) == 0)
A simple, probably incomplete and perhaps incorrect patch for
ru_inblock/ru_oublock accounting in zfs:
http://people.freebsd.org/~avg/zfs-ru.diff
Still quite better than nothing.
P.S.
This is about top -m io.
--
Andriy Gapon
___
freebsd-hackers@freebsd
Warren> Consider also the docs that tell the user to
Warren>echo 'something_enable="YES"' >> /etc/rc.conf
Warren> which can produce duplicate and possibly differing entries.
Yup! Which is exactly why I like the idea of this tool.
___
freebsd-hacker
On Thu, 7 Oct 2010, Douglas K. Rand wrote:
I think that this script might also fill a void with using Puppet as a
configuration tool. Currently Puppet, as its default behaviour, uses
files in /etc/rc.conf.d to set variables. I've found this approach
really lacking because you cannot do things li
I think that this script might also fill a void with using Puppet as a
configuration tool. Currently Puppet, as its default behaviour, uses
files in /etc/rc.conf.d to set variables. I've found this approach
really lacking because you cannot do things like:
nfs_server_enable="YES"
via a /etc/rc.
On Wed Oct 6 10, Garrett Cooper wrote:
> On Wed, Oct 6, 2010 at 4:03 PM, Garrett Cooper wrote:
> > On Wed, Oct 6, 2010 at 3:01 PM, Sergey Kandaurov wrote:
> >> On 6 October 2010 23:38, Alexander Best wrote:
> >>> On Wed Oct 6 10, Garrett Cooper wrote:
> On Wed, Oct 6, 2010 at 10:35 AM, Al
On 10/7/10 12:23 AM, jhell wrote:
Alright thank you for your explanation. I do not normally see this usage
and this just sort of stood out at me and I did not want to assume what
you were trying to accomplish, without asking.
three useage cases come to mind immediately.
1/ use within other s
On 10/07/2010 01:47, Devin Teske wrote:
>
> On Oct 6, 2010, at 9:49 PM, jhell wrote:
>
>> On 10/06/2010 23:29, Devin Teske wrote:
>>
>> I see no real advantage
>
> If you had to administer thousands of FreeBSD systems, you would.
>
Normally I have found large scale (1000's) of Unix like syste
15 matches
Mail list logo