From: Dave Chinner <david@fromorbit.com>
To: Jeff Gibson <jgibson@spscommerce.com>
Cc: "xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: XFS on top of LVM span in AWS. Stripe or are AG's good enough?
Date: Tue, 16 Aug 2016 10:59:31 +1000 [thread overview]
Message-ID: <20160816005931.GD19025@dastard> (raw)
In-Reply-To: <CY1PR04MB20100FE6C3039717BD27825AAC120@CY1PR04MB2010.namprd04.prod.outlook.com>
On Mon, Aug 15, 2016 at 11:36:14PM +0000, Jeff Gibson wrote:
> So I'm creating an LVM volume with 8 AWS EBS disks that are
> spanned (linear) per Redhat's documentation for Gluster
> (https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Deployment_Guide_for_Public_Cloud/ch02s03.html#Provisioning_Storage_for_Three-way_Replication_Volumes).
>
> 2 questions-
>
> 1. Will XFS's Allocation Groups essentially stripe the data for
> me
No. XFS does not stripe data. It does, however, *distribute* data
different AGs according to locality policy (e.g. inode32 vs
inode64), so it uses all the AGs as the directory structure grows.
> or should I stripe the underlying volumes with LVM?
No, you're using EBS. Forget anything you know about storage layout
and geometry, because EBS has no guaranteed physical layout you can
optimise for.
> I'm not
> worried as much about data integrity with a stripe/span since
> Gluster is doing the redundancy work.
>
> 2. AWS volumes sometimes have inconsistent performance. If I
> understand things correctly, AG's run in parallel.
Define "run". AGs can allocate/free blocks in parallel. If IO does
not require allocation, then AGs play no part in the IO path.
> In a
> non-striped volume, if some of the AGs are temporarily slower to
> respond than others due to one of the underlying volumes being
> slow, will XFS prefer the quicker responding AGs
No, it does not.
> or is I/O always
> evenly distributed?
No, it is not.
> If XFS prefers the more responsive AG's it
> seems to me that it would be better NOT to stripe the underlying
> disk since all AG's that are distributed in a stripe will
> continuously hit all component volumes, including the slow volume
> (unless if XFS compensates for this?)
I think you have the wrong idea about what allocation groups do.
They are for maintaining allocation concurrency and locality of
related objects on disk - they have no influence on where IO is
directed based on IO load or response time.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-08-16 0:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-15 23:36 XFS on top of LVM span in AWS. Stripe or are AG's good enough? Jeff Gibson
2016-08-16 0:59 ` Dave Chinner [this message]
2016-08-16 17:05 ` Jeff Gibson
2016-08-16 17:37 ` Eric Sandeen
2016-08-17 16:23 ` Jeff Gibson
2016-08-17 17:26 ` Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160816005931.GD19025@dastard \
--to=david@fromorbit.com \
--cc=jgibson@spscommerce.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.