qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] block: Review of .has_zero_init use


From: Kevin Wolf
Subject: Re: [Qemu-devel] block: Review of .has_zero_init use
Date: Tue, 25 Jun 2013 14:27:05 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 25.06.2013 um 14:05 hat Richard W.M. Jones geschrieben:
> On Tue, Jun 25, 2013 at 01:39:11PM +0200, Kevin Wolf wrote:
> > * ssh           - currently has_zero_init = 1 (is this correct?)
> [...]
> > It might be possible that the correct value depends on the backend on
> > the server side for some protocols - for example, I think for SSH it
> > depends on whether you access a regular file or a block device on the
> > other host (if accessing a block device is even possible).
> 
> This seems to depend on the behaviour of O_TRUNC on block devices.
> The man page says it's unspecified, but I tested it on Linux, and
> Linux ignores it (for logical volumes anyway).
> 
> When the ssh driver is asked to do bdrv_create it does on the
> remote end:
> 
>  - open (filename, O_RDWR|O_CREAT|O_TRUNC, 0644) [1]
>  - lseek (fd, size-1, SEEK_SET)                  [2]
>  - write (fd, &'\0', 1)
> 
> In other words for regular files, it creates a sparse file.  For block
> devices, I tested the sequence above, and it doesn't fail.
> 
> So .. I guess that has_zero_init = 0 would be correct?

Yes, that's my understanding.

> Unless we fstat the fd after opening it and return some conditional
> value from bdrv_has_zero_init eg if it's a block device.  Is that
> possible?

.bdrv_has_zero_init is a callback that gets a specific BlockDriverState,
so it's possible to do some checks in there. If you can get the
necessary information using SSH, doing it dynamically is certainly an
option.

Kevin



reply via email to

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