At 03:36 PM 10/27/2010, Mike Tancsa wrote:
At 01:05 PM 10/27/2010, Mike Tancsa wrote:
At 12:34 PM 10/27/2010, David Wolfskill wrote:
* release/7.1.0, with the following merged in:
r186860 from stable/7
r190970 from stable/7
r203072 from head
r209964 from stable/7
and using the MAC ke
At 01:05 PM 10/27/2010, Mike Tancsa wrote:
At 12:34 PM 10/27/2010, David Wolfskill wrote:
* release/7.1.0, with the following merged in:
r186860 from stable/7
r190970 from stable/7
r203072 from head
r209964 from stable/7
and using the MAC kernel config
* stable/8 @r214029 using the G
On 10/27/10 13:19, David Wolfskill wrote:
>> note 2x drop in performance between outer and inner tracks.
>
> OK, but I'm not sure how that's likely to work for a multi-spindle RAID
> 0 group
Unless the RAID controller is trying to be overly smart (i.e. plays with
fire) by somehow alternating
On Wed, Oct 27, 2010 at 01:06:18PM +0200, Ivan Voras wrote:
> On 10/27/10 12:55, David Wolfskill wrote:
>
> > That *is* a problem, as I cannot justify a migration to a branch
> > of FreeBSD that imposes about a 23% penalty in elapsed time on this
> > workload. I want folks at work to have more re
On 10/27/10 12:55, David Wolfskill wrote:
> That *is* a problem, as I cannot justify a migration to a branch
> of FreeBSD that imposes about a 23% penalty in elapsed time on this
> workload. I want folks at work to have more reason to want to use
> (newer branches of) FreeBSD, not less.
That is
On Wed, Oct 27, 2010 at 11:54:07AM +0200, Ivan Voras wrote:
> ...
> > the 8.x reference machine, and each terminated with a status code of 0:
> >
> > startstopreal usersys os
> > 128867 1288111298 131.14 12.77 17.88 7.1-R+
>
> > 1288109542 1288109653 111.26 12.
On 10/26/10 19:45, David Wolfskill wrote:
> On Tue, Oct 26, 2010 at 02:03:34PM +0200, Ivan Voras wrote:
>> ...
>> Since you now have the two kernels readily available, can you rule out
>> NFS by just repeating the step which involves it in both kernels and
>> compare the results?
>
> On Tue, Oct 2