All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Dan Williams <dan.j.williams@gmail.com>
Cc: Jeff Garzik <jeff@garzik.org>,
	linux-scsi@vger.kernel.org, Mauelshagen@redhat.com,
	linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
	dm-devel@redhat.com, jens.axboe@oracle.com
Subject: Re: [PATCHSET] block,scsi,libata: implement alt_size
Date: Mon, 04 May 2009 17:02:47 +0900	[thread overview]
Message-ID: <49FEA127.1000905@kernel.org> (raw)
In-Reply-To: <e9c3a7c20904301415t621670a0l1bd64c7d74d369f@mail.gmail.com>

Dan Williams wrote:
> On Thu, Apr 30, 2009 at 1:00 PM, Jeff Garzik <jeff@garzik.org> wrote:
>> Tejun Heo wrote:
>>> Hello,
>>>
>>> Jeff Garzik wrote:
>>>> <shrug>  I suppose...
>>>>
>>>> It just seems like a nasty hack, but unfortunately I don't see
>>>> anyone stepping up to do it properly -- with a DM device
>>>> automatically layered on top that splits the device into separate
>>>> regions: one block device for the 'regular' area, and one for the
>>>> HPA.
>>> Isn't that more hacky?  I don't know.  All that dm needs to know is
>>> the location of the metadata which is located w.r.t. the end of the
>>> device which might be at a different location if BIOS tried to pull
>>> silly stunts.  So, exporting the size BIOS might have used seems like
>>> a straight forward solution to me.
>> "<shrug> I suppose" is basically a reluctant ack, in the absence of other
>> solutions :)
>>
> 
> Couldn't the "fix" also just be a note to users to disable ignore_hpa
> if they notice that there raid arrays are not assembling correctly?

I don't know.  If it doesn't work automatically, the solution really
isn't worth much.  People generally don't (shouldn't need to) have any
idea what HPA is.  It basically boils down to "Linux doesn't support
RAID".  :-)

Maybe we should just put this issue to the rest and strongly advise
people against BIOS raids.

Thanks.

-- 
tejun

WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: Dan Williams <dan.j.williams@gmail.com>
Cc: Jeff Garzik <jeff@garzik.org>,
	linux-ide@vger.kernel.org, jens.axboe@oracle.com,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	James.Bottomley@hansenpartnership.com, Mauelshagen@redhat.com,
	dm-devel@redhat.com
Subject: Re: [PATCHSET] block,scsi,libata: implement alt_size
Date: Mon, 04 May 2009 17:02:47 +0900	[thread overview]
Message-ID: <49FEA127.1000905@kernel.org> (raw)
In-Reply-To: <e9c3a7c20904301415t621670a0l1bd64c7d74d369f@mail.gmail.com>

Dan Williams wrote:
> On Thu, Apr 30, 2009 at 1:00 PM, Jeff Garzik <jeff@garzik.org> wrote:
>> Tejun Heo wrote:
>>> Hello,
>>>
>>> Jeff Garzik wrote:
>>>> <shrug>  I suppose...
>>>>
>>>> It just seems like a nasty hack, but unfortunately I don't see
>>>> anyone stepping up to do it properly -- with a DM device
>>>> automatically layered on top that splits the device into separate
>>>> regions: one block device for the 'regular' area, and one for the
>>>> HPA.
>>> Isn't that more hacky?  I don't know.  All that dm needs to know is
>>> the location of the metadata which is located w.r.t. the end of the
>>> device which might be at a different location if BIOS tried to pull
>>> silly stunts.  So, exporting the size BIOS might have used seems like
>>> a straight forward solution to me.
>> "<shrug> I suppose" is basically a reluctant ack, in the absence of other
>> solutions :)
>>
> 
> Couldn't the "fix" also just be a note to users to disable ignore_hpa
> if they notice that there raid arrays are not assembling correctly?

I don't know.  If it doesn't work automatically, the solution really
isn't worth much.  People generally don't (shouldn't need to) have any
idea what HPA is.  It basically boils down to "Linux doesn't support
RAID".  :-)

Maybe we should just put this issue to the rest and strongly advise
people against BIOS raids.

Thanks.

-- 
tejun

  reply	other threads:[~2009-05-04  8:02 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-01  2:55 [PATCHSET] block,scsi,libata: implement alt_size Tejun Heo
2009-02-01  2:55 ` Tejun Heo
2009-02-01  2:55 ` [PATCH 1/3] block: add alt_size Tejun Heo
2009-02-01  2:55   ` Tejun Heo
2009-02-01  2:55 ` [PATCH 2/3] scsi: add scsi_device->alt_capacity Tejun Heo
2009-02-01  2:55   ` Tejun Heo
2009-02-01  2:55 ` [PATCH 3/3] libata: export HPA size as alt_size Tejun Heo
2009-02-01  2:55   ` Tejun Heo
2009-02-02 17:12   ` [PATCH] libata: change drive ready wait after hard reset to 5s Stuart_Hayes
2009-02-02 17:12     ` Stuart_Hayes
2009-02-02 17:17     ` Mario Limonciello
2009-02-09 21:48     ` Stuart_Hayes
2009-02-09 21:48       ` Stuart_Hayes
2009-02-01  2:59 ` [PATCHSET] dmraid: use alt_size Tejun Heo
2009-02-01  2:59 ` Tejun Heo
2009-02-01  2:59   ` Tejun Heo
2009-02-01  3:00   ` [PATCH 1/3] dmraid: set read_info to @offset by default in read_raid_dev() Tejun Heo
2009-02-01  3:00     ` Tejun Heo
2009-02-01  3:00   ` [PATCH 2/3] dmraid: add alt_size to dev_info Tejun Heo
2009-02-01  3:00     ` Tejun Heo
2009-02-01  3:01   ` [PATCH 3/3] dmraid: make nv use alt_size if available Tejun Heo
2009-02-01  3:01     ` Tejun Heo
2009-02-01  3:20 ` [PATCHSET] block,scsi,libata: implement alt_size Jeff Garzik
2009-02-01  4:14   ` Tejun Heo
2009-02-01  4:14     ` Tejun Heo
2009-04-30  1:13 ` Tejun Heo
2009-04-30  1:13 ` Tejun Heo
2009-04-30  1:13   ` Tejun Heo
2009-04-30  1:45 ` Jeff Garzik
2009-04-30  1:50   ` Tejun Heo
2009-04-30 20:00     ` Jeff Garzik
2009-04-30 21:15       ` Dan Williams
2009-04-30 21:15         ` Dan Williams
2009-05-04  8:02         ` Tejun Heo [this message]
2009-05-04  8:02           ` Tejun Heo
2009-05-04 16:48           ` Dan Williams
2009-05-05  3:28             ` Tejun Heo
2009-05-05 15:34               ` Dan Williams
2009-05-08  9:13                 ` Tejun Heo
2009-05-08 16:21                   ` Jeff Garzik
2009-05-08 16:21                     ` Jeff Garzik
2009-05-08 16:23                   ` Dan Williams

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=49FEA127.1000905@kernel.org \
    --to=tj@kernel.org \
    --cc=Mauelshagen@redhat.com \
    --cc=dan.j.williams@gmail.com \
    --cc=dm-devel@redhat.com \
    --cc=jeff@garzik.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.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.