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@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 :|