Re: [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert

2018-03-07 Thread Max Reitz
On 2018-03-07 17:33, Paolo Bonzini wrote: > On 07/03/2018 16:57, Max Reitz wrote: > (2) For sparse raw images, this is absolutely devastating. Reading them > now takes more than (ext4) or nearly (xfs) twice as much time as reading > a fully allocated image. So much for "if a filesyste

Re: [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert

2018-03-07 Thread Max Reitz
On 2018-03-07 18:05, Kevin Wolf wrote: > Am 07.03.2018 um 16:57 hat Max Reitz geschrieben: >> On 2018-03-06 18:37, Kevin Wolf wrote: >>> Am 06.03.2018 um 14:47 hat Stefan Hajnoczi geschrieben: On Wed, Feb 28, 2018 at 09:11:32PM +0100, Max Reitz wrote: > So... It's more extreme than I had

Re: [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert

2018-03-07 Thread Kevin Wolf
Am 07.03.2018 um 16:57 hat Max Reitz geschrieben: > On 2018-03-06 18:37, Kevin Wolf wrote: > > Am 06.03.2018 um 14:47 hat Stefan Hajnoczi geschrieben: > >> On Wed, Feb 28, 2018 at 09:11:32PM +0100, Max Reitz wrote: > >>> So... It's more extreme than I had hoped, that's for sure. What I > >>> conc

Re: [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert

2018-03-07 Thread Paolo Bonzini
On 07/03/2018 16:57, Max Reitz wrote: (2) For sparse raw images, this is absolutely devastating. Reading them now takes more than (ext4) or nearly (xfs) twice as much time as reading a fully allocated image. So much for "if a filesystem driver has any sense". >> Are you sure t

Re: [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert

2018-03-07 Thread Max Reitz
On 2018-03-06 18:37, Kevin Wolf wrote: > Am 06.03.2018 um 14:47 hat Stefan Hajnoczi geschrieben: >> On Wed, Feb 28, 2018 at 09:11:32PM +0100, Max Reitz wrote: >>> On 2018-02-28 19:08, Max Reitz wrote: On 2018-02-27 17:17, Stefan Hajnoczi wrote: > On Mon, Feb 26, 2018 at 06:03:13PM +0100, M

Re: [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert

2018-03-06 Thread Kevin Wolf
Am 06.03.2018 um 14:47 hat Stefan Hajnoczi geschrieben: > On Wed, Feb 28, 2018 at 09:11:32PM +0100, Max Reitz wrote: > > On 2018-02-28 19:08, Max Reitz wrote: > > > On 2018-02-27 17:17, Stefan Hajnoczi wrote: > > >> On Mon, Feb 26, 2018 at 06:03:13PM +0100, Max Reitz wrote: > > >>> There are filesy

Re: [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert

2018-03-06 Thread Stefan Hajnoczi
On Wed, Feb 28, 2018 at 09:11:32PM +0100, Max Reitz wrote: > On 2018-02-28 19:08, Max Reitz wrote: > > On 2018-02-27 17:17, Stefan Hajnoczi wrote: > >> On Mon, Feb 26, 2018 at 06:03:13PM +0100, Max Reitz wrote: > >>> There are filesystems (among which is tmpfs) that have a hard time > >>> reporting

Re: [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert

2018-02-28 Thread Max Reitz
On 2018-02-28 21:11, Max Reitz wrote: > On 2018-02-28 19:08, Max Reitz wrote: [...] > In any case it's interesting to see that even the current qemu-img > convert takes longer to read sparsely allocated qcow2/raw files from xfs > than fully allocated images... (That's because I didn't drop the c

Re: [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert

2018-02-28 Thread Max Reitz
On 2018-02-28 19:08, Max Reitz wrote: > On 2018-02-27 17:17, Stefan Hajnoczi wrote: >> On Mon, Feb 26, 2018 at 06:03:13PM +0100, Max Reitz wrote: >>> There are filesystems (among which is tmpfs) that have a hard time >>> reporting allocation status. That is definitely a bug in them. >>> >>> Howeve

Re: [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert

2018-02-28 Thread Max Reitz
On 2018-02-27 17:17, Stefan Hajnoczi wrote: > On Mon, Feb 26, 2018 at 06:03:13PM +0100, Max Reitz wrote: >> There are filesystems (among which is tmpfs) that have a hard time >> reporting allocation status. That is definitely a bug in them. >> >> However, there is no good reason why qemu-img conve

Re: [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert

2018-02-27 Thread Stefan Hajnoczi
On Mon, Feb 26, 2018 at 06:03:13PM +0100, Max Reitz wrote: > There are filesystems (among which is tmpfs) that have a hard time > reporting allocation status. That is definitely a bug in them. > > However, there is no good reason why qemu-img convert should query the > allocation status in the fi