linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Tejun Heo <tj@kernel.org>
Cc: 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: Sat, 31 Jan 2009 22:20:39 -0500	[thread overview]
Message-ID: <49851507.5040905@garzik.org> (raw)
In-Reply-To: <1233456951-992-1-git-send-email-tj@kernel.org>

Tejun Heo wrote:
> Hello,
> 
> This patchset implements alt_size, which is a size hint to the users
> of a block device.  It's primarily to communicate the BIOS (HPA) size
> on ATA devices to userland, so that dmraid can consider it when trying
> to figure out BIOS raid layout.  This is critical as dmraid can be
> tricked into assemblying the wrong raid when fed with the unlocked
> size and if the disk content is right (or, rather, wrong) and good
> number of distros are shipping with ignore_hpa=1 as default.
> 
> This patch contains the following three patches.
> 
>   0001-block-add-alt_size.patch
>   0002-scsi-add-scsi_device-alt_capacity.patch
>   0003-libata-export-HPA-size-as-alt_size.patch
> 
> Without the above three patches, I get the following on my nv RAID-0
> if HPA unlocking is turned on.
> 
>   # ~/work/dmraid/tools/dmraid -a y
>   RAID set "nvidia_djgdjigi" was activated
>   # mount /dev/dm-0 /mnt/tmp
>   mount: wrong fs type, bad option, bad superblock on /dev/dm-0,
> 	 missing codepage or helper program, or other error
> 	 In some cases useful info is found in syslog - try
> 	 dmesg | tail  or so
> 
> With the above three patches and modified dmraid,
> 
>   ck804:~/os/work/build # ~/work/dmraid/tools/dmraid -a y -v -v -v
>   ...
>   NOTICE: /dev/sdb: using BIOS sectors 234439535
>   RAID set "nvidia_djgdjigi" was activated
>   ...
>   ck804:~/os/work/build # mount /dev/dm-0 /mnt/tmp
>   ck804:~/os/work/build # umount /dev/dm-0

But the net result is that you are telling dmraid that it is OK to 
proceed, even though part of the disk it wants is really missing.  That 
seems unwise, because are you not basically proceeding with a known 
corrupt dataset at that point?

	Jeff





  parent reply	other threads:[~2009-02-01  3:20 UTC|newest]

Thread overview: 25+ 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 ` [PATCH 1/3] block: add alt_size Tejun Heo
2009-02-01  2:55 ` [PATCH 2/3] scsi: add scsi_device->alt_capacity Tejun Heo
2009-02-01  2:55 ` [PATCH 3/3] libata: export HPA size as alt_size Tejun Heo
2009-02-02 17:12   ` [PATCH] libata: change drive ready wait after hard reset to 5s Stuart_Hayes
2009-02-02 17:17     ` Mario Limonciello
2009-02-09 21:48     ` Stuart_Hayes
2009-02-01  2:59 ` [PATCHSET] dmraid: use alt_size 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   ` [PATCH 2/3] dmraid: add alt_size to dev_info Tejun Heo
2009-02-01  3:01   ` [PATCH 3/3] dmraid: make nv use alt_size if available Tejun Heo
2009-02-01  3:20 ` Jeff Garzik [this message]
2009-02-01  4:14   ` [PATCHSET] block,scsi,libata: implement alt_size 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-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: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=49851507.5040905@garzik.org \
    --to=jeff@garzik.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=Mauelshagen@RedHat.com \
    --cc=dm-devel@RedHat.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).