xfs
[Top] [All Lists]

Re: XFS Performance on NetApp

To: xfs@xxxxxxxxxxx, Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS Performance on NetApp
From: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 27 Oct 2010 01:57:03 +0200
In-reply-to: <20101026231007.GA32255@dastard>
Organization: it-management http://it-management.at
References: <201010270033.35894@xxxxxx> <20101026231007.GA32255@dastard>
User-agent: KMail/1.13.5 (Linux/2.6.34.7-0.4-desktop; KDE/4.4.4; x86_64; ; )
On Mittwoch, 27. Oktober 2010 Dave Chinner wrote:
> However, options that
> reduce filesystem fragmentation (e.g. allocsize) still have value in
> keeping the amount of metadata and ptotential seeks down...

Yes, but for NetApp: maybe. With this whole deduplication thingy, I 
wonder if even such a simple assumption is true. And then some people 
make a snapshot every hour, whichmeans your log will wander around on 
the storage anyway. So it's best to "just use it".

Another thing just crosses my mind: on a thin provisioned system, would 
the TRIM command be useful? Do such storages recognise this command? It 
would be very clever, I think. Let's say you run xfs_fsr, that would 
allow the upper layer to relaim unused space. Would that be the storage 
or XenServer/VMware which needs to understand this command?

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

it-management Internet Services
http://proteger.at [gesprochen: Prot-e-schee]
Tel: 0660 / 415 65 31

****** Radiointerview zum Thema Spam ******
http://www.it-podcast.at/archiv.html#podcast-100716

// Wir haben im Moment zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/

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

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