> The new 2tb disk you buy can very often be actually a few sectors
> smaller then the disk you are trying to replace, this in turn will
> lead to zfs not accepting the new disk as a replacement, because it's
> smaller (no matter how small).
Heh - you are in for a pleasent surprise my friend! ;-)
If this is true, some magic has been done to the FreeBSD port of ZFS,
because according to SUN documentation is is definitely not supposed
to be possible.
- Dan Naumov
On Mon, Jun 15, 2009 at 10:48 AM, Pete
French wrote:
>> The new 2tb disk you buy can very often be actually a few sectors
>> sma
> If this is true, some magic has been done to the FreeBSD port of ZFS,
> because according to SUN documentation is is definitely not supposed
> to be possible.
I just tried it again to make sure I wasn't imagining things - you
can give it a shot yourself using mdconfig to create some drives. It
w
Haven't had time to test (stuck at work), but I will trust your word
:) Well, this sounds nice and sensible. I am curious though if there
have been any numbers regarding how much do "actual" drive sizes vary
in the real world when it comes to disks of same
manufacturer/model/size. I guess this prob
Hi.
This is on 6.4-S as of April with uptime about 2 months.
Machine could not be accessed via network, didn't reply on ping.
Looking at backtrace it's here:
if_bce.c::bce_get_buf():
/* This is a new mbuf allocation. */
MGETHDR(m_new, M_DONTWAIT, MT_DATA);
>From
> Haven't had time to test (stuck at work), but I will trust your word
> :) Well, this sounds nice and sensible. I am curious though if there
It's good isn't it ? I just did another test, replacing both drives
wuth smaller ones, and you can't then recursively add an even smaller one
in :-) If you
This is 6.4-stable from April.
System locks up while in `sysctl dev.cpu` (with coretemp kldloaded).
So as far as I understand sched_bind() binds an executing thread to
nonexistent CPU 255.
Same behavior on coretemp built on 6.2.
db> ps
pid ppid pgrp uid state wmesg wchancmd
343
2009/6/15 pluknet :
> This is 6.4-stable from April.
>
> System locks up while in `sysctl dev.cpu` (with coretemp kldloaded).
Small follow-up:
Just one of my wild guesses is that coretemp doesn't play nice with ncpu > 4.
A problem box is 8-way cpu. I always observe this lockup when
sched_bind(cur
I just merged a change from current to libstand which increases the number
of open file descriptors. This could be what was causing your problems.
Can you test it out with the latest RELENG_7?
On Sun, Jun 14, 2009 at 7:08 PM, Dan Allen wrote:
>
> On 14 Jun 2009, at 5:08 PM, Daniel Eischen wrot
Hi,
the custom kernel, I've built on my home router catched a panic today.
I don't have any dump, because swap is encrypted. I've got some
information written by hand... I hope it helps a bit.
fault virtual address = 0xa
fault code = supervisor read, page not present
instruction pointer = 0x20:0
Freddie Cash writes:
> On Sun, Jun 14, 2009 at 9:17 AM, Dan Naumov wrote:
>
> > I just wanted to have an extra pair (or a dozen) of eyes look this
> > configuration over before I commit to it (tested it in VMWare just in
> > case, it works, so I am considering doing this on real hardware soo
On Mon, Jun 15, 2009 at 8:47 AM, George Hartzell wrote:
> Freddie Cash writes:
> > On Sun, Jun 14, 2009 at 9:17 AM, Dan Naumov
> wrote:
> >
> > > I just wanted to have an extra pair (or a dozen) of eyes look this
> > > configuration over before I commit to it (tested it in VMWare just in
> >
On Sunday 14 June 2009 7:08:50 pm Daniel Eischen wrote:
> On Sun, 14 Jun 2009, Dan Allen wrote:
>
> >
> > On 14 Jun 2009, at 1:27 AM, Daniel Eischen wrote:
> >
> >> From one of your older emails, you mention you are using
> >> ad0s2a as / and ad0s2b as swap, and then say that ad0s2c
> >> is unused
On Monday 15 June 2009 4:49:06 am pluknet wrote:
> Hi.
>
> This is on 6.4-S as of April with uptime about 2 months.
> Machine could not be accessed via network, didn't reply on ping.
> Looking at backtrace it's here:
>
> if_bce.c::bce_get_buf():
> /* This is a new mbuf allocation.
Hello,
On Fri, May 29, 2009 at 8:16 PM, Marius Strobl wrote:
> On Fri, May 29, 2009 at 08:02:42PM +0200, Henri-Pierre Charles wrote:
>> Hello Guys
>>
>> On Thu, Apr 23, 2009 at 10:05 PM, Jeff Blank wrote:
>> > On Thu, Apr 23, 2009 at 07:19:49PM +0200, Marius Strobl wrote:
>> >> So in combination
2009/6/15 pluknet :
> 2009/6/15 pluknet :
>> This is 6.4-stable from April.
>>
>> System locks up while in `sysctl dev.cpu` (with coretemp kldloaded).
>
> Small follow-up:
>
> Just one of my wild guesses is that coretemp doesn't play nice with ncpu > 4.
> A problem box is 8-way cpu. I always observ
One of the changes in FreeBSD 8.0 is the removal of support for the KSE
threading library and its associated system calls. What this means in
practice is that if one uses a KSE-based libpthread from 5.x or 6.x in a
chroot or jail on an 8.0 system, the binaries will fail with SIGSYS. For
most
Did we change something in the routing socket's datagram between 7.0 and
7.2? I have a binary I compiled on 7.0-RELEASE and it fails to add a route
on 7.2. If I recompile the source on 7.2, it works. Roughly put, the code
make a datagram for the route socket like this:
bzero(&rtmsg, siz
18 matches
Mail list logo
