xfs
[Top] [All Lists]

Re: XFS setting custom extent size: real-time section only?

To: Heilige Gheist <hgheist@xxxxxxxxx>
Subject: Re: XFS setting custom extent size: real-time section only?
From: Nathan Scott <nathans@xxxxxxx>
Date: Tue, 25 Jul 2006 08:43:56 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20060724110338.62600.qmail@web31709.mail.mud.yahoo.com>; from hgheist@yahoo.com on Mon, Jul 24, 2006 at 04:03:38AM -0700
References: <20060724100030.E2083275@wobbly.melbourne.sgi.com> <20060724110338.62600.qmail@web31709.mail.mud.yahoo.com>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Mon, Jul 24, 2006 at 04:03:38AM -0700, Heilige Gheist wrote:
> I've checked source code of 2.6.16.13-4 in SUSE 10.1, it looks like
> this limitation is no longer there.
> However the lack of support for this in SLES9 complicates things a bit,
> for example we're using EMC PowerPath 4.5.1 for MPIO and it doesn't
> support anything but SLES9 SP2. Hardware driver support is shaky as
> well.

OK.  Are you certain you need this feature?  (can you describe your
usage a bit?)  You can get large contiguous chunks of disk space via
large direct writes for example, or preallocation, so maybe you could
attack the issue from a different angle to solve it?

> Provided I have to stick with whatever kernel support there's in SLES9,
> what are the implications of running large volumes (150-300GB) as one
> big real-time section?

I'm not sure off the top of my head (SLES9 SP2 is relatively old now) if
the realtime subvolume support there had support for buffered writes (it
used to be direct IO only), I suspect it predated that change too.

> Do I have to have non-realtime regular section?

Yes.  All metadata is stored there.

> Should I expect a performance hit due to large size of real-time
> section?

It depends. :)  For single disk, I've never seen realtime not outperform
the btree allocator, for RAIDs and multiple writers I suspect you might
find a different picture.  You'd really have to try it and see how your
specific application(s) perform.

cheers.

-- 
Nathan


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