From: Stan Hoeppner <stan@hardwarefreak.com>
To: xfs@oss.sgi.com
Subject: Re: SL's kickstart corrupting XFS by "repairing" GPT labels?
Date: Wed, 06 Apr 2011 12:19:59 -0500 [thread overview]
Message-ID: <4D9CA0BF.9010706@hardwarefreak.com> (raw)
In-Reply-To: <20110406114146.GF31057@dastard>
Dave Chinner put forth on 4/6/2011 6:41 AM:
> On Wed, Apr 06, 2011 at 12:19:00PM +0200, Jan Kundrát wrote:
>> zerombr yes
>> clearpart --all --initlabel
>> part swap --size=1024 --asprimary
>> part / --fstype ext3 --size=0 --grow --asprimary
>
> There your problem - hello random crap....
Yep, most likely.
> Given the nature of the problem, I have to assume you aren't using
> FC zoning to prevent hosts from seeing disks that don't belong to
> them?
Switch soft zoning isn't even required to avoid this kind of mess. The
Nexsan arrays (as with many/most others) have built in LUN security,
allowing you to unmask a LUN to only specific WWNs of specific HBAs.
With Nexsan products, by default, no LUNs are unmasked after creating a
virtual disk and assigning a LUN to it. One must then manually unmask a
LUN to one or more HBA WWNs.
Their are basically only 3 scenarios when you would assign more than one
HBA WWN to a given LUN:
1. multi-pathing between two (or more) FC ports on one host
2. shared disk cluster filesystem such as CXFS, GFS2, or OCFS.
3. passive fail over high availability
Some folks assign "everything to everything" on their FC SAN for various
not so well considered reasons, without realizing the consequences.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2011-04-06 17:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-06 10:19 SL's kickstart corrupting XFS by "repairing" GPT labels? Jan Kundrát
2011-04-06 11:41 ` Dave Chinner
2011-04-06 14:31 ` Jan Kundrát
2011-04-06 17:19 ` Stan Hoeppner [this message]
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=4D9CA0BF.9010706@hardwarefreak.com \
--to=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