From: "Richard W.M. Jones" <rjones@redhat.com>
To: Mykola Ivanets <stenavin@gmail.com>,
pbonzini@redhat.com, qemu-devel@nongnu.org,
qemu-block@nongnu.org
Cc: libguestfs@redhat.com
Subject: Re: [Libguestfs] [RFC] lib: allow to specify physical/logical block size for disks
Date: Mon, 10 Feb 2020 11:43:16 +0000 [thread overview]
Message-ID: <20200210114316.GW3888@redhat.com> (raw)
In-Reply-To: <20200207232528.13461-1-stenavin@gmail.com>
On Sat, Feb 08, 2020 at 01:25:28AM +0200, Mykola Ivanets wrote:
> From: Nikolay Ivanets <stenavin@gmail.com>
>
> I faced with situation where libguestfs cannot recognize partitions on a
> disk image which was partitioned on a system with "4K native" sector
> size support.
Do you have a small test case for this?
> In order to fix the issue we need to allow users to specify desired
> physical and/or logical block size per drive basis.
It seems like physical_block_size / logical_block_size in qemu are
completely undocumented. However I did some experiments with patching
libguestfs and examining the qemu and parted code. Here are my
observations:
(1) Setting only physical_block_size = 4096 seems to do nothing.
(2) Setting only logical_block_size = 4096 is explicitly rejected by
virtio-scsi:
https://git.qemu.org/?p=qemu.git;a=blob;f=hw/scsi/scsi-disk.c;h=10d0794d60f196f177563aae00bed2181f5c1bb1;hb=HEAD#l2352
(A similar test exists for virtio-blk)
(3) Setting both physical_block_size = logical_block_size = 4096
changes how parted partitions GPT disks. The partition table is
clearly using 4K sectors as you can see by examining the disk
afterwards with hexdump.
(4) Neither setting changes MBR partitioning by parted, although my
interpretation of Wikipedia indicates that it should be possible to
create a MBR disk with 4K sector size. Maybe I'm doing something
wrong, or parted just doesn't support this case.
So it appears that we should just have one blocksize control (maybe
called "sectorsize"?) which sets both physical_block_size and
logical_block_size to the same value. It may also be worth enforcing
that blocksize/sectorsize must be set to 512 or 4096 (which we can
relax later if necessary).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
next parent reply other threads:[~2020-02-10 11:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200207232528.13461-1-stenavin@gmail.com>
2020-02-10 11:43 ` Richard W.M. Jones [this message]
2020-02-10 12:28 ` [Libguestfs] [RFC] lib: allow to specify physical/logical block size for disks Nikolay Ivanets
2020-02-10 13:02 ` Richard W.M. Jones
2020-02-10 13:52 ` Nikolay Ivanets
2020-02-10 13:48 ` Kevin Wolf
2020-02-10 14:15 ` Nikolay Ivanets
2020-02-10 14:41 ` Richard W.M. Jones
2020-02-10 19:10 ` Paolo Bonzini
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=20200210114316.GW3888@redhat.com \
--to=rjones@redhat.com \
--cc=libguestfs@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stenavin@gmail.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;
as well as URLs for NNTP newsgroup(s).