public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Stan Hoeppner <stan@hardwarefreak.com>
Cc: Eric Sandeen <sandeen@sandeen.net>, xfs@oss.sgi.com
Subject: Re: makefs alignment issue
Date: Mon, 27 Oct 2014 10:43:25 +1100	[thread overview]
Message-ID: <20141026234325.GB6880@dastard> (raw)
In-Reply-To: <544BDF55.9040804@hardwarefreak.com>

On Sat, Oct 25, 2014 at 12:35:17PM -0500, Stan Hoeppner wrote:
> If the same interface is used for Linux logical block devices (md, dm,
> lvm, etc) and hardware RAID, I have a hunch it may be better to
> determine that, if possible, before doing anything with these values.
> As you said previously, and I agree 100%, a lot of RAID vendors don't
> export meaningful information here.  In this specific case, I think the
> RAID engineers are exporting a value, 1 MB, that works best for their
> cache management, or some other path in their firmware.  They're
> concerned with host interface xfer into the controller, not the IOs on
> the back end to the disks.  They don't see this as an end-to-end deal.
> In fact, I'd guess most of these folks see their device as performing
> magic, and it doesn't matter what comes in or goes out either end.
> "We'll take care of it."

Deja vu. This is an isochronous RAID array you are having trouble
with, isn't it?

FWIW, do your problems go away when you make you hardware LUN width
a multiple of the cache segment size?

> optimal_io_size.  I'm guessing this has different meaning for different
> folks.  You say optimal_io_size is the same as RAID width.  Apply that
> to this case:
> 
> hardware RAID 60 LUN, 4 arrays
> 16+2 RAID6, 256 KB stripe unit, 4096 KB stripe width
> 16 MB LUN stripe width
> optimal_io_size = 16 MB
> 
> Is that an appropriate value for optimal_io_size even if this is the
> RAID width?  I'm not saying it isn't.  I don't know.  I don't know what
> other layers of the Linux and RAID firmware stacks are affected by this,
> nor how they're affected.

yup, i'd expect minimum = 4MB (i.e stripe unit 4MB so we align to
the underlying RAID6 luns) and optimal = 16MB for the stripe width
(and so with swalloc we align to the first lun in the RAID0).

This should be passed up unchanged through the stack if none of the
software layers are doing other geometry modifications (e.g. more
raid, thinp, etc).

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2014-10-26 23:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-24 20:11 makefs alignment issue Stan Hoeppner
2014-10-24 20:14 ` Eric Sandeen
2014-10-24 22:08   ` Stan Hoeppner
2014-10-24 22:19     ` Eric Sandeen
2014-10-24 22:27       ` Eric Sandeen
2014-10-25  3:08         ` Stan Hoeppner
2014-10-25 15:51           ` Eric Sandeen
2014-10-25 17:35             ` Stan Hoeppner
2014-10-26 23:43               ` Dave Chinner [this message]
2014-10-27 23:04                 ` Stan Hoeppner
2014-10-28  0:32                   ` Dave Chinner
2014-10-28 16:55                     ` Stan Hoeppner

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=20141026234325.GB6880@dastard \
    --to=david@fromorbit.com \
    --cc=sandeen@sandeen.net \
    --cc=stan@hardwarefreak.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox