On Apr 1, 2010, at 12:43 AM, tomwaters wrote:
> "If you see the workload on the wire go through regular patterns of fast/slow
> response
> then there are some additional tricks that can be applied to increase the
> overall
> throughput and smooth the jaggies. But that is fodder for another post.
"If you see the workload on the wire go through regular patterns of fast/slow
response
then there are some additional tricks that can be applied to increase the
overall
throughput and smooth the jaggies. But that is fodder for another post..."
Can you pls. elaborate on what can be done here as I
On Mar 26, 2010, at 2:34 AM, Bruno Sousa wrote:
> Hi,
>
> The jumbo-frames in my case give me a boost of around 2 mb/s, so it's not
> that much.
That is about right. IIRC, the theoretical max is about 4% improvement, for
MTU of 8KB.
> Now i will play with link aggregation and see how it goes
Hi,
The jumbo-frames in my case give me a boost of around 2 mb/s, so it's
not that much.
Now i will play with link aggregation and see how it goes, and of course
i'm counting that incremental replication will be slower...but since the
amount of data would be much less probably it will still delive
Hi,
I think that in this case the cpu is not the bottleneck, since i'm not
using ssh.
However my 1gb network link probably is the bottleneck.
Bruno
On 26-3-2010 9:25, Erik Ableson wrote:
>
> On 25 mars 2010, at 22:00, Bruno Sousa wrote:
>
>> Hi,
>>
>> Indeed the 3 disks per vdev (raidz2) seems
On 25 mars 2010, at 22:00, Bruno Sousa wrote:
Hi,
Indeed the 3 disks per vdev (raidz2) seems a bad idea...but it's the
system i have now.
Regarding the performance...let's assume that a bonnie++ benchmark
could go to 200 mg/s in. The possibility of getting the same values
(or near) in a
On 03/26/10 10:00 AM, Bruno Sousa wrote:
[Boy top-posting sure mucks up threads!]
Hi,
Indeed the 3 disks per vdev (raidz2) seems a bad idea...but it's the
system i have now.
Regarding the performance...let's assume that a bonnie++ benchmark
could go to 200 mg/s in. The possibility of getting
Hi,
Indeed the 3 disks per vdev (raidz2) seems a bad idea...but it's the
system i have now.
Regarding the performance...let's assume that a bonnie++ benchmark could
go to 200 mg/s in. The possibility of getting the same values (or near)
in a zfs send / zfs receive is just a matter of putting , let
On 03/26/10 08:47 AM, Bruno Sousa wrote:
Hi all,
The more readings i do about ZFS, and experiments the more i like this
stack of technologies.
Since we all like to see real figures in real environments , i might
as well share some of my numbers ..
The replication has been achieved with the zfs
Thanks for the tip..btw is there any advantage with jbod vs simple volumes?
Bruno
On 25-3-2010 21:08, Richard Jahnel wrote:
> BTW, if you download the solaris drivers for the 52445 from adaptec, you can
> use jbod instead of simple volumes.
>
smime.p7s
Description: S/MIME Cryptographic Sig
BTW, if you download the solaris drivers for the 52445 from adaptec, you can
use jbod instead of simple volumes.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/lis
Hi all,
The more readings i do about ZFS, and experiments the more i like this
stack of technologies.
Since we all like to see real figures in real environments , i might as
well share some of my numbers ..
The replication has been achieved with the zfs send / zfs receive but
piped with mbuffer (h
12 matches
Mail list logo