All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Avi Kivity <avi@qumranet.com>
Cc: KVM list <kvm@vger.kernel.org>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: 63 sectors
Date: Wed, 03 Sep 2008 13:26:31 +0200	[thread overview]
Message-ID: <48BE7467.3080900@redhat.com> (raw)
In-Reply-To: <48BE46DD.1070703@qumranet.com>

> I can think of a few workarounds, all bad:
> - add a partitioning tool (or option to qemu-img) to format the disk,
> placing the first partition on the fourth cylinder, aligning it.  tell
> the users not to wipe the disks out but instead install to one of the
> existing parititions

Well, that one slightly modified could work out quite well, at least for
linux.

As far I know the linux kernel uses the geometry provided by the storage
adapter only in case the disk is blank.  If there is a partition table
present on the disk, the linux kernel will calculate the geometry based
on that.

Background for this is that scsi disks have no disk geometry, they just
have a bunch of sectors.  The scsi hostadapter bioses have to pull out
some geometry out of thin air to satisfy ms-dos and real os boot
loaders, and there was no standard on how to do that.  Thus moving disks
from one scsi adapter to another may result in hba-reported and on-disk
geometry being different, and the only sane way to deal with that is
using the on-disk geometry.  With LBA this is much less an issue these
days though.

So qemu-img could create a partition table, containing one partition,
hinting 32 sectors/cylinder.  Linux should keep that geometry then, even
when distro installers are deleting the partition and creating their own
scheme.

Dunno how what *BSD or Windows guests will deal with that though.

cheers,
  Gerd


  parent reply	other threads:[~2008-09-03 11:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-03  8:12 63 sectors Avi Kivity
2008-09-03  8:35 ` David Mair
2008-09-03  9:32   ` Avi Kivity
2008-09-03 11:26 ` Gerd Hoffmann [this message]
2008-09-04  8:49   ` Gerd Hoffmann
2008-09-03 16:15 ` H. Peter Anvin
2008-09-04  3:20 ` Liu Yu-B13201
2008-09-04  3:33   ` H. Peter Anvin
2008-09-04  3:39     ` Liu Yu-B13201
2008-09-04  3:56       ` H. Peter Anvin
2008-09-04  7:47         ` Itamar Heim
2008-09-07  8:20           ` Avi Kivity
2008-09-04  8:58 ` Ian Kirk
2008-09-04 11:15   ` Laurent Vivier
2008-09-04 12:18   ` H. Peter Anvin
2008-09-04 13:56     ` H. Peter Anvin
2008-09-04 17:56   ` Charles Duffy

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=48BE7467.3080900@redhat.com \
    --to=kraxel@redhat.com \
    --cc=avi@qumranet.com \
    --cc=hpa@zytor.com \
    --cc=kvm@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.