On 02/10/2010, at 11:43 AM, Artem Belevich wrote:
>> As soon as I opened this email I knew what it would say.
>>
>>
>> # time zfs send storage/bac...@transfer | mbuffer | zfs receive
>> storage/compressed/bacula-mbuffer
>> in @ 197 MB/s, out @ 205 MB/s, 1749 MB total, buffer 0% full
> ..
>>
On Fri, Oct 1, 2010 at 8:43 PM, Artem Belevich wrote:
>> As soon as I opened this email I knew what it would say.
>>
>>
>> # time zfs send storage/bac...@transfer | mbuffer | zfs receive
>> storage/compressed/bacula-mbuffer
>> in @ 197 MB/s, out @ 205 MB/s, 1749 MB total, buffer 0% full
> ...
> As soon as I opened this email I knew what it would say.
>
>
> # time zfs send storage/bac...@transfer | mbuffer | zfs receive
> storage/compressed/bacula-mbuffer
> in @ 197 MB/s, out @ 205 MB/s, 1749 MB total, buffer 0% full
...
> Big difference. :)
I'm glad it helped.
Does anyone know wh
On 10/1/2010 7:00 PM, Artem Belevich wrote:
On Fri, Oct 1, 2010 at 3:49 PM, Dan Langille wrote:
FYI: this is all on the same box.
In one of the previous emails you've used this command line:
# mbuffer -s 128k -m 1G -I 9090 | zfs receive
You've used mbuffer in network client mode. I assumed
On 30 Sep, Don Lewis wrote:
> The silent reboots that I was seeing with WITNESS go away if I add
> WITNESS_SKIPSPIN. Witness doesn't complain about anything.
I've tracked down the the silent reboot problem. It happens when a
userland sysctl call gets down into calcru1(), which tries to print a
FYI: this is all on the same box.
--
Dan Langille
http://langille.org/
On Oct 1, 2010, at 5:56 PM, Artem Belevich wrote:
> Hmm. It did help me a lot when I was replicating ~2TB worth of data
> over GigE. Without mbuffer things were roughly in the ballpark of your
> numbers. With mbuffer I've
On Fri, Oct 1, 2010 at 3:49 PM, Dan Langille wrote:
> FYI: this is all on the same box.
In one of the previous emails you've used this command line:
> # mbuffer -s 128k -m 1G -I 9090 | zfs receive
You've used mbuffer in network client mode. I assumed that you did do
your transfer over network.
Hmm. It did help me a lot when I was replicating ~2TB worth of data
over GigE. Without mbuffer things were roughly in the ballpark of your
numbers. With mbuffer I've got around 100MB/s.
Assuming that you have two boxes connected via ethernet, it would be
good to check that nobody generates PAUSE f
On Fri, Oct 01, 2010 at 02:51:12PM -0400, Dan Langille wrote:
>
> On Wed, September 29, 2010 2:04 pm, Dan Langille wrote:
> > $ zpool iostat 10
> >capacity operationsbandwidth
> > pool used avail read write read write
> > -- - - -
On Wed, September 29, 2010 2:04 pm, Dan Langille wrote:
> $ zpool iostat 10
>capacity operationsbandwidth
> pool used avail read write read write
> -- - - - - - -
> storage 7.67T 5.02T358 38 43.1M 1.96M
> s
Quoting Kostik Belousov :
On Sun, Sep 19, 2010 at 07:28:13PM -0300, Mario Sergio Fujikawa
Ferreira wrote:
Hi,
I've just began trying chrome web browser from
http://chromium.hybridsource.org/ but it triggered 2 panics on my
8.1-STABLE system.
$ uname -a
FreeBSD exxodus.fedaykin.here
On Sep 29, 2010, at 10:07 AM, Jeremy Chadwick wrote:
> On Wed, Sep 29, 2010 at 09:57:53AM -0700, Chuck Swiger wrote:
>>
>> I doubt repeated coincidences. :-) Is prime95 testing running stable after
>> waking from sleep?
>
> He's not running Prime95 (native Win32 app), he's running
> ports/math
TB --- 2010-10-01 12:12:52 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-10-01 12:12:52 - starting RELENG_8 tinderbox run for mips/mips
TB --- 2010-10-01 12:12:52 - cleaning the object tree
TB --- 2010-10-01 12:14:04 - cvsupping the source tree
TB --- 2010-10-01 12:14:04 - /usr/b
On Fri, October 1, 2010 11:45 am, Dan Langille wrote:
>
> On Wed, September 29, 2010 3:57 pm, Artem Belevich wrote:
>> On Wed, Sep 29, 2010 at 11:04 AM, Dan Langille wrote:
>>> It's taken about 15 hours to copy 800GB. I'm sure there's some tuning
>>> I
>>> can do.
>>>
>>> The system is now runni
On Wed, September 29, 2010 3:57 pm, Artem Belevich wrote:
> On Wed, Sep 29, 2010 at 11:04 AM, Dan Langille wrote:
>> It's taken about 15 hours to copy 800GB. I'm sure there's some tuning I
>> can do.
>>
>> The system is now running:
>>
>> # zfs send storage/bac...@transfer | zfs receive
>> stora
> On Fri, Oct 01, 2010 at 01:20:42PM +0200, Daniel Braniss wrote:
> > > On Fri, Oct 01, 2010 at 09:26:41AM +0200, Daniel Braniss wrote:
> > > > In a not so distant past, boot0cfg -sn ... used to work, then it only
> > > > partialy worked, it would modify the data in boot but not the mbr, for
> > >
On Fri, 1 Oct 2010 04:34:34 -0700
Jeremy Chadwick wrote:
> Anyway, if the MBR did get updated without kern.geom.debugflags having
> bit 4 set, then wouldn't this indicate there's a bug in GEOM's "sector
> 0" protection?
Or that it knows that updating the active byte is harmless.
--
Bruce Cran
On Thu, Sep 30, 2010 at 09:03:33AM +0200, Ed Schouten wrote:
> * Jeremy Chadwick wrote:
> > 1) "mysqld_safe > /dev/null 2>&1 &" never released the tty
> > 2) "nohup mysqld_safe > /dev/null 2>&1 &" did release the tty
> What happens if you run the following command?
> daemon -cf mysqld_safe
On Fri, Oct 01, 2010 at 01:20:42PM +0200, Daniel Braniss wrote:
> > On Fri, Oct 01, 2010 at 09:26:41AM +0200, Daniel Braniss wrote:
> > > In a not so distant past, boot0cfg -sn ... used to work, then it only
> > > partialy worked, it would modify the data in boot but not the mbr, for
> > > which 'g
> On Fri, Oct 01, 2010 at 09:26:41AM +0200, Daniel Braniss wrote:
> > In a not so distant past, boot0cfg -sn ... used to work, then it only
> > partialy worked, it would modify the data in boot but not the mbr, for
> > which 'gpart -s set active -in ...' modified the mbr. Now
> > # boot0cfg -s1 -v
On Fri, Oct 01, 2010 at 09:26:41AM +0200, Daniel Braniss wrote:
> In a not so distant past, boot0cfg -sn ... used to work, then it only
> partialy worked, it would modify the data in boot but not the mbr, for
> which 'gpart -s set active -in ...' modified the mbr. Now
> # boot0cfg -s1 -v /dev/mfid0
Luke Marsden writes:
> On Thu, 2010-09-30 at 18:55 -0400, Jung-uk Kim wrote:
> > It seems MCA capability is advertised by the CPUID translator but
> > writing to the MSRs causes GPF. In other words, it seems like a CPU
> > emulator bug. A simple workaround is 'set hw.mca.enabled=0' from the
> pkg_version -IoL=
graphics/dri>
java/eclipse-eclemma!
graphics/libGL >
graphics/libGLU >
graphics/libdrm >
graphics/libglut>
graphics/mesa-demos >
games/openare
In a not so distant past, boot0cfg -sn ... used to work, then it only
partialy worked, it would modify the data in boot but not the mbr, for
which 'gpart -s set active -in ...' modified the mbr. Now
# boot0cfg -s1 -v /dev/mfid0
boot0cfg: write_mbr: /dev/mfid0: Operation not permitted
but:
# boot0cf
24 matches
Mail list logo
