[libvirt] [PATCH 2/9] storage: Always assume we are tracking alloc progress in FS backend

[Daniel P. Berrange]

On Fri, Jul 10, 2009 at 04:46:59PM -0400, Cole Robinson wrote:
> We do support allocation progress now, so have the code accomodate.
> ---
>  src/storage_backend_fs.c |   49 +++++++++++++++-------------------------------
>  1 files changed, 16 insertions(+), 33 deletions(-)

Do later patches have a dependancy on this ?

The allocation progress tracking you mention is actually WRT to
a 2nd thread calling virStorageVolGetInfo while the first thread
is doing the work. AFAIK, that would not be impacted by either 
of these 2 code paths.  The 'track_allocation_progress' variable
was a placeholder for the case where we do proper async non-blocking
vol creation from a single thread.

By switching this code to use the iterative allocation, it will 
increase the number of ext4 extents required for large files 
which is not so desirable. So I think its better to just leave
this code in as is, or remove the other code path.

Daniel

> 
> diff --git a/src/storage_backend_fs.c b/src/storage_backend_fs.c
> index 64a7130..c7c1c9c 100644
> --- a/src/storage_backend_fs.c
> +++ b/src/storage_backend_fs.c
> @@ -72,8 +72,6 @@ typedef int (*createFile)(virConnectPtr conn,
>                            virStorageVolDefPtr vol,
>                            virStorageVolDefPtr inputvol);
>  
> -static int track_allocation_progress = 0;
> -
>  /* Either 'magic' or 'extension' *must* be provided */
>  struct FileTypeInfo {
>      int type;           /* One of the constants above */
> @@ -1108,38 +1106,23 @@ static int createRaw(virConnectPtr conn,
>  
>      /* Pre-allocate any data if requested */
>      /* XXX slooooooooooooooooow on non-extents-based file systems */
> -    if (remain) {
> -        if (track_allocation_progress) {
> -
> -            while (remain) {
> -                /* Allocate in chunks of 512MiB: big-enough chunk
> -                 * size and takes approx. 9s on ext3. A progress
> -                 * update every 9s is a fair-enough trade-off
> -                 */
> -                unsigned long long bytes = 512 * 1024 * 1024;
> -                int r;
> -
> -                if (bytes > remain)
> -                    bytes = remain;
> -                if ((r = safezero(fd, 0, vol->allocation - remain,
> -                                  bytes)) != 0) {
> -                    virReportSystemError(conn, r,
> -                                         _("cannot fill file '%s'"),
> -                                         vol->target.path);
> -                    goto cleanup;
> -                }
> -                remain -= bytes;
> -            }
> -        } else { /* No progress bars to be shown */
> -            int r;
> -
> -            if ((r = safezero(fd, 0, 0, remain)) != 0) {
> -                virReportSystemError(conn, r,
> -                                     _("cannot fill file '%s'"),
> -                                     vol->target.path);
> -                goto cleanup;
> -            }
> +    while (remain) {
> +        /* Allocate in chunks of 512MiB: big-enough chunk
> +         * size and takes approx. 9s on ext3. A progress
> +         * update every 9s is a fair-enough trade-off
> +         */
> +        unsigned long long bytes = 512 * 1024 * 1024;
> +        int r;
> +
> +        if (bytes > remain)
> +            bytes = remain;
> +        if ((r = safezero(fd, 0, vol->allocation - remain, bytes)) != 0) {
> +            virReportSystemError(conn, r,
> +                                 _("cannot fill file '%s'"),
> +                                 vol->target.path);
> +            goto cleanup;
>          }
> +        remain -= bytes;
>      }
>  
>      if (close(fd) < 0) {
> -- 
> 1.6.0.6
> 
> --
> Libvir-list mailing list
> Libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list

-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|