On May 7, 2012, at 1:53 PM, Edward Ned Harvey wrote:
>> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
>> boun...@opensolaris.org] On Behalf Of Bob Friesenhahn
>>
>> Has someone done real-world measurements which indicate that raidz*
>> actually provides better sequential read or
On Mon, 7 May 2012, Edward Ned Harvey wrote:
Apparently I pulled it down at some point, so I don't have a URL for you
anymore, but I did, and I posted. Long story short, both raidzN and mirror
configurations behave approximately the way you would hope they do. That
is...
Approximately, as com
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Paul Kraus
>
> Even with uncompressable data I measure better performance with
> compression turned on rather than off.
*cough*
___
zfs-discus
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Bob Friesenhahn
>
> Has someone done real-world measurements which indicate that raidz*
> actually provides better sequential read or write than simple
> mirroring with the same number of disks
On May 5, 2012, at 8:04 AM, Bob Friesenhahn wrote:
> On Fri, 4 May 2012, Erik Trimble wrote:
>> predictable, and the backing store is still only giving 1 disk's IOPS. The
>> RAIDZ* may, however, give you significantly more throughput (in MB/s) than a
>> single disk if you do a lot of sequentia
On 5/5/2012 8:04 AM, Bob Friesenhahn wrote:
On Fri, 4 May 2012, Erik Trimble wrote:
predictable, and the backing store is still only giving 1 disk's
IOPS. The RAIDZ* may, however, give you significantly more
throughput (in MB/s) than a single disk if you do a lot of sequential
read or write.
On Fri, 4 May 2012, Erik Trimble wrote:
predictable, and the backing store is still only giving 1 disk's IOPS. The
RAIDZ* may, however, give you significantly more throughput (in MB/s) than a
single disk if you do a lot of sequential read or write.
Has someone done real-world measurements wh
On 5/4/2012 1:24 PM, Peter Tribble wrote:
On Thu, May 3, 2012 at 3:35 PM, Edward Ned Harvey
wrote:
I think you'll get better, both performance& reliability, if you break each
of those 15-disk raidz3's into three 5-disk raidz1's. Here's why:
Incorrect on reliability; see below.
Now, to put
On Thu, May 3, 2012 at 3:35 PM, Edward Ned Harvey
wrote:
>
> I think you'll get better, both performance & reliability, if you break each
> of those 15-disk raidz3's into three 5-disk raidz1's. Here's why:
Incorrect on reliability; see below.
> Now, to put some numbers on this...
> A single 1T
On Thu, May 03, 2012 at 07:35:45AM -0700, Edward Ned Harvey wrote:
> > From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> > boun...@opensolaris.org] On Behalf Of Ray Van Dolson
> >
> > System is a 240x2TB (7200RPM) system in 20 Dell MD1200 JBODs. 16 vdevs of
> > 15
> > disks each --
On Thu, May 3, 2012 at 7:47 AM, Edward Ned Harvey wrote:
> Given the amount of ram you have, I really don't think you'll be able to get
> any useful metric out of iozone in this lifetime.
I still think it would be apropos if dedup and compression were being
used. In that case, does filebench have
On Thu, May 3, 2012 at 10:39 AM, Edward Ned Harvey
wrote:
>> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
>> boun...@opensolaris.org] On Behalf Of Paul Kraus
>>
>> If you have compression turned on (and I highly recommend turning
>> it on if you have the CPU power to handle i
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Bob Friesenhahn
>
> Zfs is all about caching so the cache really does need to be included
> (and not intentionally broken) in any realistic measurement of how the
> system will behave.
I agree
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Paul Kraus
>
> If you have compression turned on (and I highly recommend turning
> it on if you have the CPU power to handle it),
What if he's storing video files, compressed files, or en
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Ray Van Dolson
>
> System is a 240x2TB (7200RPM) system in 20 Dell MD1200 JBODs. 16 vdevs of
> 15
> disks each -- RAIDZ3. NexentaStor 3.1.2.
I think you'll get better, both performance & rel
more comments...
On May 1, 2012, at 10:41 AM, Ray Van Dolson wrote:
> On Tue, May 01, 2012 at 07:18:18AM -0700, Bob Friesenhahn wrote:
>> On Mon, 30 Apr 2012, Ray Van Dolson wrote:
>>
>>> I'm trying to run some IOzone benchmarking on a new system to get a
>>> feel for baseline performance.
>>
>
On Tue, 1 May 2012, Ray Van Dolson wrote:
Testing multi-threaded synchronous writes with IOzone might actually
mean something if it is representative of your work-load.
Sounds like IOzone may not be my best option here (though it does
produce pretty graphs).
bonnie++ actually gave me more rea
On Tue, May 1, 2012 at 1:45 PM, Gary wrote:
> The idea of benchmarking -- IMHO -- is to vaguely attempt to reproduce
> real world loads. Obviously, this is an imperfect science but if
> you're going to be writing a lot of small files (e.g. NNTP or email
> servers used to be a good real world exam
On 5/1/12, Ray Van Dolson wrote:
> The problem is this box has 144GB of memory. If I go with a 16GB file
> size (which I did), then memory and caching influences the results
> pretty severely (I get around 3GB/sec for writes!).
The idea of benchmarking -- IMHO -- is to vaguely attempt to reprodu
On Tue, May 01, 2012 at 07:18:18AM -0700, Bob Friesenhahn wrote:
> On Mon, 30 Apr 2012, Ray Van Dolson wrote:
>
> > I'm trying to run some IOzone benchmarking on a new system to get a
> > feel for baseline performance.
>
> Unfortunately, benchmarking with IOzone is a very poor indicator of
> wha
On Tue, May 01, 2012 at 03:21:05AM -0700, Gary Driggs wrote:
> On May 1, 2012, at 1:41 AM, Ray Van Dolson wrote:
>
> > Throughput:
> >iozone -m -t 8 -T -r 128k -o -s 36G -R -b bigfile.xls
> >
> > IOPS:
> >iozone -O -i 0 -i 1 -i 2 -e -+n -r 128K -s 288G > iops.txt
>
> Do you expect to be r
On Mon, 30 Apr 2012, Ray Van Dolson wrote:
I'm trying to run some IOzone benchmarking on a new system to get a
feel for baseline performance.
Unfortunately, benchmarking with IOzone is a very poor indicator of
what performance will be like during normal use. Forcing the system
to behave lik
On Mon, Apr 30, 2012 at 4:15 PM, Ray Van Dolson wrote:
> I'm trying to run some IOzone benchmarking on a new system to get a
> feel for baseline performance.
If you have compression turned on (and I highly recommend turning
it on if you have the CPU power to handle it), the IOzone data will
On May 1, 2012, at 1:41 AM, Ray Van Dolson wrote:
> Throughput:
>iozone -m -t 8 -T -r 128k -o -s 36G -R -b bigfile.xls
>
> IOPS:
>iozone -O -i 0 -i 1 -i 2 -e -+n -r 128K -s 288G > iops.txt
Do you expect to be reading or writing 36 or 288Gb files very often on
this array? The largest file
24 matches
Mail list logo