xfs
[Top] [All Lists]

Re: separate log and structure from user data device?

To: Peter Grandi <pg_xfs@xxxxxxxxxxxxxxxxxx>
Subject: Re: separate log and structure from user data device?
From: Nathan Scott <nathans@xxxxxxx>
Date: Fri, 9 Jun 2006 08:50:26 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <17544.12555.858981.847208@xxxxxxxxxxxxxxxxxx>; from pg_xfs@xxxxxxxxxxxxxxxxxx on Thu, Jun 08, 2006 at 03:15:39PM +0100
References: <Pine.LNX.4.58.0606051402410.18047@xxxxxxxxxxx> <8630.1149517148@xxxxxxxxxxxxxxx> <20060606101258.B644608@xxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0606061553320.31122@xxxxxxxxxxx> <20060608104242.I710447@xxxxxxxxxxxxxxxxxxxxxxxx> <17544.12555.858981.847208@xxxxxxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Thu, Jun 08, 2006 at 03:15:39PM +0100, Peter Grandi wrote:
> 
> [ ... curious complaints about write performance ... ]
> 
> >> /* O_DIRECT for "realtime" */
> 
> nathans> You don't need O_DIRECT for realtime these days.
> 
> >> assert( (fid = open(pn,
> >>   O_WRONLY|O_CREAT|O_DIRECT|O_SYNC|O_LARGEFILE)) != -1 );
> 
> nathans> Thats a shocking use of assert. :)
> 
> Thats too kind :-).
> 
> However, I am puzzled as you comment on 'O_DIRECT' but not on
> 'O_SYNC'. IIRC XFS performance, and in particular the strategy

Heh, I completely overlooked the O_SYNC there.

> to used to allocate large extents, is based on hugely delayed
> flushing, and 'O_SYNC' would defeat that, resulting perhaps in

Indeed.

> the allocation of many small extents, and this might impact
> write speed too (more metadata writes). Is this plausible?

Indeed.

cheers.

-- 
Nathan


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