From: Jamie Lokier <jamie@shareable.org>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel@nongnu.org, Rusty Russell <rusty@rustcorp.com.au>,
Christoph Hellwig <hch@lst.de>,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size
Date: Tue, 5 Jan 2010 20:16:15 +0000 [thread overview]
Message-ID: <20100105201615.GJ14376@shareable.org> (raw)
In-Reply-To: <4B433783.6090400@redhat.com>
Avi Kivity wrote:
> On 01/05/2010 02:56 PM, Rusty Russell wrote:
> >
> >>Those should be the same for any sane interface. They are for classical
> >>disk devices with larger block sizes (MO, s390 dasd) and also for the
> >>now appearing 4k sector scsi disks. But in the ide world people are
> >>concerned about dos/window legacy compatiblity so they came up with a
> >>nasty hack:
> >>
> >> - there is a physical block size as used by the disk internally
> >> (4k initially)
> >> - all the interfaces to the operating system still happen in the
> >> traditional 512 byte blocks to not break any existing assumptions
> >> - to make sure modern operating systems can optimize for the larger
> >> physical sectors the disks expose this size, too.
> >> - even worse disks can also have alignment hacks for the traditional
> >> DOS partitions tables, so that the 512 byte block zero might even
> >> have an offset into the first larger physical block. This is also
> >> exposed in the ATA identify information.
> >>
> >>All in all I don't think this mess is a good idea to replicate in
> >>virtio. Virtio by defintion requires virtualization aware guests, so we
> >>should just follow the SCSI way of larger real block sizes here.
> >>
> >Yes. The current VIRTIO_BLK_F_BLK_SIZE says "please use this block size".
> >We haven't actually specified what happens if the guest doesn't, but the
> >spec says "must", and the Linux implementation does so AFAICT.
> >
> >If we want a "soft" size, we could add that as a separate feature.
> >
>
> No - I agree with Christoph, there's no reason to use a 512/4096
> monstrosity with virtio.
It would be good if virtio relayed the backing device's basic topology
hints, so:
- If the backing dev is a real disk with 512-byte sectors,
virtio should indicate 512-byte blocks to the guest.
- If the backing dev is a real disk with 4096-byte sectors,
virtio should indicate 4096-byte blocks to the guest.
With databases and filesystems, if you care about data integrity:
- If the backing dev is a real disk with 4096-byte sectors,
or a file whose access is through a 4096-byte-per-page cache,
virtio must indicate 4096-byte blocks otherwise guest
journalling is not host-powerfail safe.
You get the idea. If there is only one parameter, it really should be
at least as large as the smallest unit which may be corrupted by
writes when errors occur.
-- Jamie
next prev parent reply other threads:[~2010-01-05 20:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1262018363-15871-1-git-send-email-avi@redhat.com>
2010-01-04 3:08 ` [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size Rusty Russell
2010-01-04 7:02 ` Avi Kivity
2010-01-05 20:18 ` Jamie Lokier
2010-01-04 8:30 ` Christoph Hellwig
2010-01-05 12:56 ` Rusty Russell
2010-01-05 12:58 ` Avi Kivity
2010-01-05 20:16 ` Jamie Lokier [this message]
2010-01-08 15:40 ` Christoph Hellwig
2010-01-10 12:35 ` Avi Kivity
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=20100105201615.GJ14376@shareable.org \
--to=jamie@shareable.org \
--cc=avi@redhat.com \
--cc=hch@lst.de \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.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).