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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
