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

Re: Simplified protocol?



On Sun, Nov 18, 2018 at 03:03:37PM +0100, Wouter Verhelst wrote:
> On Thu, Nov 15, 2018 at 06:05:48PM +0000, Richard W.M. Jones wrote:
> > On Thu, Nov 15, 2018 at 04:23:41PM +0100, Wouter Verhelst wrote:
> > > Actually, nbd-client defaults to 1024, and has done that for a *long*
> > > time :-)
> > 
> > Yes this is really annoying because it means that the default is to
> > always fail when you loopback mount a partitioned disk image.
> 
> That's not been my experience; partitioned devices seemed to always use
> the block size of the original device, not of the NBD representation.
> However, that was using MBR partitions, never with GPT; perhaps the
> difference is there? Alternatively, it's been a while since I last
> tested, and it might of course be that the Linux kernel's behaviour has
> changed in the mean time.

It's certainly very reproducible with nbdkit which doesn't advertise a
preferred block size.  For the test below I'm using:

  nbdkit-1.9.1-1.fc30.x86_64 (server)
  nbd-3.18-1.fc30.x86_64 (client)
  kernel 4.18.13-200.fc28.x86_64 (client)

With MBR:

  $ truncate -s 1G fs.img
  $ mkfs -t ext4 fs.img
  $ nbdkit partitioning partition-type=mbr fs.img -f -v

  # nbd-client localhost /dev/nbd0
  # mount /dev/nbd0p1 /tmp/mnt
  [  302.443798]  nbd0: p1
  [  302.443897] nbd0: p1 size 4194304 extends beyond EOD, truncated

With GPT:

  $ nbdkit partitioning partition-type=gpt fs.img -f -v

  # nbd-client localhost /dev/nbd0

The kernel doesn't even find the partition in the GPT case, and nor
does ‘gdisk -l /dev/nbd0’.

In both cases, this is fixed by using the ‘nbd-client -b 512’ option.

It's also reproducible by using OS images, so it's nothing to do with
bugs in nbdkit's partitioning plugin.

> > The Linux kernel assumes a 1K sector size and computes all partition
> > offsets wrongly.  Can we change this?
> 
> I could. But my plan was to implement block size negotiations when next
> I have time, and then use whatever's negotiated at that level as the
> block size that I send to the kernel. For now, it seems better to keep
> the defaults that have been around for a long time, rather than change
> things twice.

I would disagree since the out of the box case obviously doesn't work.
I don't think there is any common system that uses a 1K sector size.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html


Reply to: