qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libguestfs] [RFC] lib: allow to specify physical/logical block size


From: Nikolay Ivanets
Subject: Re: [Libguestfs] [RFC] lib: allow to specify physical/logical block size for disks
Date: Mon, 10 Feb 2020 14:28:08 +0200

пн, 10 лют. 2020 о 13:43 Richard W.M. Jones <address@hidden> пише:
>
> On Sat, Feb 08, 2020 at 01:25:28AM +0200, Mykola Ivanets wrote:
> > From: Nikolay Ivanets <address@hidden>
> >
> > 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?

We can easily create one with patched libguestfs and attach disk to
unpatched libguestfs.

> > 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.

See my thoughts on this in previous email.

> (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).

If we stick with the only parameter, I think blocksize might be better name,
especially if we want to split this parameter somewhere latter.

Here are more precise restrictions:

Both values must be a power of 2 between 512 and 32768.
logical_block_size must be
less or equals to physical_block_size.

--
  Mykola Ivanets



reply via email to

[Prev in Thread] Current Thread [Next in Thread]