[Top] [All Lists]

Re: 30 TB RAID6 + XFS slow write performance

To: xfs@xxxxxxxxxxx
Subject: Re: 30 TB RAID6 + XFS slow write performance
From: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 24 Jul 2011 10:47:14 +0200
Cc: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, John Bokma <contact@xxxxxxxxxxxxx>
In-reply-to: <4E2BB859.1050200@xxxxxxxxxxxxxxxxx>
Organization: it-management http://it-management.at
References: <4E24907F.6020903@xxxxxxxxxxxxx> <20110722231040.GD13963@dastard> <4E2BB859.1050200@xxxxxxxxxxxxxxxxx>
User-agent: KMail/1.13.6 (Linux/; KDE/4.6.0; x86_64; ; )
On Sonntag, 24. Juli 2011 Stan Hoeppner wrote:
> Is the NetApp FC/iSCSI attachment performance still competitive for
> large file/streaming IO, given that one can't optimize XFS stripe
> alignment, and with no indication of where the file fragments are
> actually written on the media?  Or does it lag behind something like
> a roughly equivalent class Infinite Storage array, or IBM DS?

I can't tell about performance difference. But I'd like to explain two 
fundamental differences to all other storages:

1) WAFL *never* overwrites an existing block. Whenver there's a write to 
an existing block, that block is instead written to a new location, 
afterwards the old block mapped to the new one. This is a key factor to 
keeping performance up when using snapshots and deduplication.

2) WAFL never does small or random writes. All writes are collected in 
NVRAM, and then written as one large sequential write, always one full 
stripe is written.

That means for workloads with lots of small random writes, NetApp 
storages beat the hell out of the disks, compared to other storages.
I can't tell for large seq. writes, though, I don't have such workload.

mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531

// Haus zu verkaufen: http://zmi.at/langegg/

Attachment: signature.asc
Description: This is a digitally signed message part.

<Prev in Thread] Current Thread [Next in Thread>