xfs
[Top] [All Lists]

RE: Review: Concurrent Multi-File Data Streams

To: "'Andi Kleen'" <andi@xxxxxxxxxxxxxx>
Subject: RE: Review: Concurrent Multi-File Data Streams
From: "David Chatterton" <dchatterton@xxxxxxxxxx>
Date: Tue, 15 May 2007 10:15:50 +1000
Cc: "'xfs-dev'" <xfs-dev@xxxxxxx>, "'xfs-oss'" <xfs@xxxxxxxxxxx>, "'David Chinner'" <dgc@xxxxxxx>
In-reply-to: <20070514223946.GA19487@xxxxxxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
Thread-index: AceWeMpxeBXomGDQT3ag+pGdmo367AACszxA
Andi,

Dave just beat me to it, this represents the workload used by all
post-production houses since they moved to digital where each stream is
320MB/s (2K format) or 1.3GB/s (4K format). Making sure those files are
written sequentially on disk and do not overlap other streams has a huge
benefit when supporting multiple streams.

There is no reason why other workloads that would benefit from files in the
same directory being written sequentially into their "own AG" would not use
this feature. Post-production just tends to push the filesystem to the
limits earlier than some other workloads.

David



> -----Original Message-----
> From: Andi Kleen [mailto:andi@xxxxxxxxxxxxxx] 
> Sent: Tuesday, 15 May 2007 8:40 AM
> To: David Chatterton
> Cc: 'Andi Kleen'; 'xfs-dev'; 'xfs-oss'; 'David Chinner'
> Subject: Re: Review: Concurrent Multi-File Data Streams
> 
> > So yes this is designed for a workload where the number of AGs is a 
> > multiple of the number of streams since mixing streams in 
> the one AG 
> > is the problem it tries to avoid.
> 
> Sounds like a awful special case. Is that common? 
> 
> -Andi
> 


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