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(a)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 :|