On Tue, Jan 05, 2010 at 08:16:15PM +0000, Jamie Lokier wrote:
> 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.

It's not that easy.  IDE only supports larger sectors sizes with the
physical sector size attribute, not native larger sectors.  While scsi
does support it it's untypical and I would not expect the guests to
not always get it right.  So the best is to use the transport native
way to express that we have larger sectors and expect the guest to do
the right thing.

I've done some work on the autodetection of the larger sector sizes
a while ago.  But now that people brought up migration I wonder if that
makes sense - if we migrate from a 512 byte sector size disk to a 4096
byte sector size disk we can't simply change guest visible attributes.

Maybe we should pick one on image creation and then stick to it.  For an
image format we could write down this information in the image, but for
a raw images that's impossible.

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Reply via email to