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@xxxxxxxxxx
> 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 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list