All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@cfl.rr.com>
To: Tejun Heo <tj@kernel.org>
Cc: device-mapper development <dm-devel@redhat.com>,
	Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
	"Hawrylewicz Czarnowski,
	Przemyslaw" <przemyslaw.hawrylewicz.czarnowski@intel.com>
Subject: Re: HPA unlock during partition scan of RAID components
Date: Fri, 04 Nov 2011 12:26:02 -0400	[thread overview]
Message-ID: <4EB4121A.1060102@cfl.rr.com> (raw)
In-Reply-To: <20111104155228.GY4417@google.com>

On 11/4/2011 11:52 AM, Tejun Heo wrote:
>> Could you clarify what issues you refer to?  Moving a drive to
>> another machine?
>
> Yeah, that or hotplugging, or changing BIOS config, updating BIOS,
> and, some (rare) BIOSen even fail to set up things consistently across
> reboots.

I'm asking for a clarification not just a restatement.  What problem 
occurs when you move a drive to another machine, or hotplug the drive?

> Exposing alt size should be enough for md/dm no matter how hpa is
> setup.

So you are saying that mdadm should store the metadata for 0.9 and 1.0 
relative to the locked end of the disk, even if it is currently 
unlocked?  I suppose then grub also will need to be able to detect if 
the disk has been unlocked and adjust to using the locked size.

>> Being able to defeat the heuristic would help, but I still don't see
>> why the heuristic should be implemented in the kernel instead of
>> user space?
>
> Because sans raids, it was good enough and doesn't recent md's have
> metadata at the beginning anyway?

It isn't about whether it is good enough or not, it's about whether the 
kernel should be using heuristics to make decisions, or leaving it up to 
user space, where distros can come up with all kinds of complex logic to 
handle all of the goofy cases.  You complain that the block layer does 
not have enough information to get it right, so why not let user space 
decide, where it has access to all of the information it needs.

> The thing is that you have your problem, and other people have other
> issues w/ HPA.  At this point, it's a misfeature abused by some silly
> BIOSen mostly for silly BIOS raids.  I think we should expose the most
> we can to our users and if some BIOSen are screwed on soft reboot,
> well, just accept it or turn off HPA unlocking manually.

It is actually not used FOR the bios raid.  The bios is using the HPA 
for unrelated reasons and it just happens that unlocking it breaks the 
bios raid ( and mdadm with format 0.9 or 1.0 ).

  reply	other threads:[~2011-11-04 16:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <74AAB12B538EC94087A0D16AFDFC24F4045674@IRSMSX102.ger.corp.intel.com>
2011-11-03 15:54 ` HPA unlock during partition scan of RAID components Tejun Heo
2011-11-03 19:00   ` Phillip Susi
2011-11-04 14:48     ` Tejun Heo
2011-11-04 15:42       ` Phillip Susi
2011-11-04 15:52         ` Tejun Heo
2011-11-04 16:26           ` Phillip Susi [this message]
2011-11-04 16:32             ` Tejun Heo
2011-11-04 21:08               ` Phillip Susi
2011-11-04 21:50                 ` Tejun Heo
2011-11-05  1:29                   ` Phillip Susi
2011-11-05  1:43                     ` Tejun Heo
2011-11-05  2:26                       ` Phillip Susi
2011-11-05  2:52                         ` Tejun Heo
2011-11-05  3:50                           ` Phillip Susi
2011-11-03 20:46   ` NeilBrown
2011-11-03 21:08     ` Tejun Heo
2012-05-15  0:50       ` Charles Nordlund

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=4EB4121A.1060102@cfl.rr.com \
    --to=psusi@cfl.rr.com \
    --cc=bzolnier@gmail.com \
    --cc=dm-devel@redhat.com \
    --cc=przemyslaw.hawrylewicz.czarnowski@intel.com \
    --cc=tj@kernel.org \
    /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.