From: Flavio <fbc...@gm...> - 2007-01-18 13:19:45
|
Hello, I recently downloaded vanilla kernel sources from www.kernel.org. I compiled the sources on my host system to do a performance test, also using "time". My CPU is an Intel centrino core duo at 2Ghz. To compile my vanilla testing kernel I did: make defconfig time make -j3 Results: real: 1m54,535s user: 3m16,800s sys: 0m18,920s Very good... ;) I started UML and i did the same thing.. compiling a vanilla kernel with the same config file.. uml # make defconfig uml # time make -j3 These are the results!!!! real 8m45.393s user 2m53.770s sys 0m30.310s O_O It's simply incredible!!!! Why performances decrease in this way???? UML is in skas3 mode. Command line is "linux ubd0=rootfs.debian ubd1=swapfs.debian eth0=tuntap,,,192.168.1.110 mem=1000M" Please, tell me what can I do... That time is to high!!! Thanks, Flavio. |
From: Jeff D. <jd...@ad...> - 2007-01-18 22:19:40
|
On Thu, Jan 18, 2007 at 02:19:39PM +0100, Flavio wrote: > Please, tell me what can I do... That time is to high!!! The usual recommendations are to make sure that your /tmp or /dev/shm is tmpfs and that your rootfs image isn't sparse. Also, are you sure the two cases are comparable? Same kernel tree being built with the same configuration, same gcc version? Jeff -- Work email - jdike at linux dot intel dot com |
From: Flavio <fbc...@gm...> - 2007-01-18 22:41:14
|
Thank you very much Jeff, # cat /etc/fstab, give me this: none /dev/shm tmpfs nodev,nosuid,defaults 0 0 So, I think it's correct. I don't know exactly what you mean, for sparse, (it may be you are talking about filesystem capacity) but the root filesystem size is about 1,5 GB. gcc version on my gentoo host system is 4.1.1-r1 gcc on guest (debian) system is: 3.3.5 ... I'm going to upgrade it. In both cases I did "make defconfig" in the root kernel dir. Thanks, Flavio 2007/1/18, Jeff Dike <jd...@ad...>: > On Thu, Jan 18, 2007 at 02:19:39PM +0100, Flavio wrote: > > Please, tell me what can I do... That time is to high!!! > > The usual recommendations are to make sure that your /tmp or /dev/shm > is tmpfs and that your rootfs image isn't sparse. > > Also, are you sure the two cases are comparable? Same kernel tree > being built with the same configuration, same gcc version? > > Jeff > > -- > Work email - jdike at linux dot intel dot com > |
From: Flavio <fbc...@gm...> - 2007-01-18 22:41:43
|
Thank you very much Jeff, # cat /etc/fstab, give me this: none /dev/shm tmpfs nodev,nosuid,defaults 0 0 So, I think it's correct. I don't know exactly what you mean, for sparse, (it may be you are talking about filesystem capacity) but the root filesystem size is about 1,5 GB. gcc version on my gentoo host system is 4.1.1-r1 gcc on guest (debian) system is: 3.3.5 ... I'm going to upgrade it. In both cases I did "make defconfig" in the root kernel dir. Thanks, Flavio 2007/1/18, Jeff Dike <jd...@ad...>: > On Thu, Jan 18, 2007 at 02:19:39PM +0100, Flavio wrote: > > Please, tell me what can I do... That time is to high!!! > > The usual recommendations are to make sure that your /tmp or /dev/shm > is tmpfs and that your rootfs image isn't sparse. > > Also, are you sure the two cases are comparable? Same kernel tree > being built with the same configuration, same gcc version? > > Jeff > > -- > Work email - jdike at linux dot intel dot com > |
From: Flavio <fbc...@gm...> - 2007-01-18 23:08:14
|
Nothing to do... I just compiled the kernel again, "make defconfig && make -j3" on guest system. This is the time command output: real 7m30.144s user 2m32.970s sys 0m24.600s The double of the time required by the host system to compile the same thing. The double is unacceptable, for me. How is it possible??? Bye. Flavio. 2007/1/18, Flavio <fbc...@gm...>: > Thank you very much Jeff, > > # cat /etc/fstab, give me this: > none /dev/shm tmpfs > nodev,nosuid,defaults 0 0 > > So, I think it's correct. > I don't know exactly what you mean, for sparse, (it may be you are > talking about filesystem capacity) but the root filesystem size is > about 1,5 GB. > > gcc version on my gentoo host system is 4.1.1-r1 > gcc on guest (debian) system is: 3.3.5 ... I'm going to upgrade it. > > In both cases I did "make defconfig" in the root kernel dir. > > Thanks, > > Flavio > > 2007/1/18, Jeff Dike <jd...@ad...>: > > On Thu, Jan 18, 2007 at 02:19:39PM +0100, Flavio wrote: > > > Please, tell me what can I do... That time is to high!!! > > > > The usual recommendations are to make sure that your /tmp or /dev/shm > > is tmpfs and that your rootfs image isn't sparse. > > > > Also, are you sure the two cases are comparable? Same kernel tree > > being built with the same configuration, same gcc version? > > > > Jeff > > > > -- > > Work email - jdike at linux dot intel dot com > > > |
From: Jeff D. <jd...@ad...> - 2007-01-18 23:46:53
|
On Thu, Jan 18, 2007 at 11:41:41PM +0100, Flavio wrote: > I don't know exactly what you mean, for sparse, (it may be you are > talking about filesystem capacity) but the root filesystem size is > about 1,5 GB. Sparse means that the file isn't fully backed by disk, i.e. the actual space occupied is less than the file size. Someone noticed a month or two ago that UML is noticably faster with fully backed filesystems than with sparse ones. Jeff -- Work email - jdike at linux dot intel dot com |
From: Flavio <fbc...@gm...> - 2007-01-19 06:12:53
|
OK! If I did understand correctly you mean that I should have a root filefilesystem filled up nearly. If there's a lot of not occupied space, performances are decreased.. Thanks Flavio 2007/1/19, Jeff Dike <jd...@ad...>: > On Thu, Jan 18, 2007 at 11:41:41PM +0100, Flavio wrote: > > I don't know exactly what you mean, for sparse, (it may be you are > > talking about filesystem capacity) but the root filesystem size is > > about 1,5 GB. > > Sparse means that the file isn't fully backed by disk, i.e. the actual > space occupied is less than the file size. Someone noticed a month or > two ago that UML is noticably faster with fully backed filesystems > than with sparse ones. > > Jeff > > -- > Work email - jdike at linux dot intel dot com > |
From: Antoine M. <an...@na...> - 2007-01-19 08:25:19
|
Flavio wrote: > OK! > If I did understand correctly you mean that I should have a root > filefilesystem filled up nearly. > If there's a lot of not occupied space, performances are decreased.. Almost, but not quite. It depends on how the filesystem is created. Sparse files will show the free space in the guest but without using any space on the host. Unless you specifically created a sparse file, this is not your problem, if you are using skas3 - this is as fast as it is going to be... unfortunately. Antoine > > Thanks > > Flavio > > 2007/1/19, Jeff Dike <jd...@ad...>: >> On Thu, Jan 18, 2007 at 11:41:41PM +0100, Flavio wrote: >>> I don't know exactly what you mean, for sparse, (it may be you are >>> talking about filesystem capacity) but the root filesystem size is >>> about 1,5 GB. >> Sparse means that the file isn't fully backed by disk, i.e. the actual >> space occupied is less than the file size. Someone noticed a month or >> two ago that UML is noticably faster with fully backed filesystems >> than with sparse ones. >> >> Jeff >> >> -- >> Work email - jdike at linux dot intel dot com >> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > |
From: Blaisorblade <bla...@ya...> - 2007-01-19 23:57:59
|
On Thursday 18 January 2007 14:19, Flavio wrote: > Hello, > > I recently downloaded vanilla kernel sources from www.kernel.org. > I compiled the sources on my host system to do a performance test, > also using "time". > > My CPU is an Intel centrino core duo at 2Ghz. I.e. a SMP processor obviously, right? > To compile my vanilla testing kernel I did: > > make defconfig > time make -j3 > > Results: > > real: 1m54,535s > user: 3m16,800s > sys: 0m18,920s > > Very good... ;) > > I started UML and i did the same thing.. compiling a vanilla kernel > with the same config file.. > > uml # make defconfig > uml # time make -j3 > > These are the results!!!! > > real 8m45.393s > user 2m53.770s > sys 0m30.310s > > O_O > > It's simply incredible!!!! Why performances decrease in this way???? UML does not support SMP, so it can use just one processor. This is the major slowdown case in your comparison. Compare make -j2 on the host and on the guest: there will still be some slowdown, but not such an high one. Possibly on the guest make -j1 could be better (it would be interesting). Also, the user time is less on UML. The fact that total time is higher is probably due to running with -j3 on a uniprocessor machine, and the fact that the user time is less is probably due to using gcc 3.3 rather than 4 (I seem to recall gcc 4 is slower in compilation than gcc 3). > UML is in skas3 mode. > Command line is "linux ubd0=rootfs.debian ubd1=swapfs.debian > eth0=tuntap,,,192.168.1.110 mem=1000M" > > Please, tell me what can I do... That time is to high!!! -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
From: Flavio <fbc...@gm...> - 2007-01-20 16:39:19
|
2007/1/20, Blaisorblade <bla...@ya...>: > I.e. a SMP processor obviously, right? That's right! > UML does not support SMP, so it can use just one processor. This is the major > slowdown case in your comparison. > > Compare make -j2 on the host and on the guest: there will still be some > slowdown, but not such an high one. Possibly on the guest make -j1 could be > better (it would be interesting). host # time make -j2 real 1m54.358s user 3m9.300s sys 0m18.910s guest # time make -j2 real 7m37.511s user 2m32.770s sys 0m23.200s guest # time make -j1 real 7m41.003s user 2m33.880s sys 0m23.230s :-( ''' > > Also, the user time is less on UML. The fact that total time is higher is > probably due to running with -j3 on a uniprocessor machine, and the fact that > the user time is less is probably due to using gcc 3.3 rather than 4 (I seem > to recall gcc 4 is slower in compilation than gcc 3). I'm using gcc 4 on both systems. Thank you very much. Bye, Flavio |
From: Blaisorblade <bla...@ya...> - 2007-01-23 07:28:59
|
On Saturday 20 January 2007 17:39, Flavio wrote: > 2007/1/20, Blaisorblade <bla...@ya...>: > > I.e. a SMP processor obviously, right? > > That's right! > > > UML does not support SMP, so it can use just one processor. This is the > > major slowdown case in your comparison. > > > > Compare make -j2 on the host and on the guest: there will still be some > > slowdown, but not such an high one. Possibly on the guest make -j1 could > > be better (it would be interesting). > > host # time make -j2 > real 1m54.358s > user 3m9.300s > sys 0m18.910s Er, it seems that _I_ gave you a wrong suggestion - it is still using both processor (though not optimally), so "time make -j1" on _both_ the host and the guest is a fairer comparison. The confusion was born since on a uniprocessor machine it is usually suggested to use make -j2. However, make -j2 on a dual core will use both processors. > guest # time make -j2 > real 7m37.511s > user 2m32.770s > sys 0m23.200s > > guest # time make -j1 > real 7m41.003s > user 2m33.880s > sys 0m23.230s > > :-( ''' > : > > Also, the user time is less on UML. The fact that total time is higher is > > probably due to running with -j3 on a uniprocessor machine, and the fact > > that the user time is less is probably due to using gcc 3.3 rather than 4 > > (I seem to recall gcc 4 is slower in compilation than gcc 3). -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
From: Antoine M. <an...@na...> - 2007-01-23 17:31:27
|
How about attaching a disk with mconsole, mount it in the guest, copy the data, umount, detach disk. done? Chris Lightfoot wrote: > On Tue, Jan 23, 2007 at 12:14:53PM -0500, Jonas Meyer wrote: >> Hmm... What is the preferred method of backup for a VM then? As I >> said, I'd rather not install ssh on every guest if I don't have to. > > depends how consistent a backup you need and what level of > resource usage you can tolerate. e.g. you could pause the > VM, copy the whole filesystem, and back up the result > (accepting that you'll modify the copy when mounting it). > or you could make a snapshot of the block device > underlying the VMs' filesystems and then back that up > however you want. etc. > |
From: Joel P. <joe...@mi...> - 2007-01-23 19:29:18
|
I use NFS for having the guests mount separate directories on the host, then I rsync to these from the UMLs. Works for me, and is easily cron:able from inside the UMLs. This was convenient since my host have a directory with shared resources for the UMLs anyway, so NFS was already set up. If you're working in a safe environment I guess you could also have the host mount the UMLs' roots via NFS and have the host perform the rsync. But I realize that if you're hesitant to install SSH, NFS isn't a much better alternative. :-) // Joel On Tue, 23 Jan 2007, Antoine Martin wrote: > How about attaching a disk with mconsole, mount it in the guest, copy > the data, umount, detach disk. done? > > Chris Lightfoot wrote: >> On Tue, Jan 23, 2007 at 12:14:53PM -0500, Jonas Meyer wrote: >>> Hmm... What is the preferred method of backup for a VM then? As I >>> said, I'd rather not install ssh on every guest if I don't have to. >> >> depends how consistent a backup you need and what level of >> resource usage you can tolerate. e.g. you could pause the >> VM, copy the whole filesystem, and back up the result >> (accepting that you'll modify the copy when mounting it). >> or you could make a snapshot of the block device >> underlying the VMs' filesystems and then back that up >> however you want. etc. >> > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > |
From: Flavio <fbc...@gm...> - 2007-01-23 09:20:01
|
OK!! Thank you. So, I can't get better performances now. I'm going to integrate some HPC clustering system to speed up UML even though I don't know if it's the right way... becouse of the I/O latency time. Bye. Flavio 2007/1/23, Blaisorblade <bla...@ya...>: > On Saturday 20 January 2007 17:39, Flavio wrote: > > 2007/1/20, Blaisorblade <bla...@ya...>: > > > I.e. a SMP processor obviously, right? > > > > That's right! > > > > > UML does not support SMP, so it can use just one processor. This is the > > > major slowdown case in your comparison. > > > > > > Compare make -j2 on the host and on the guest: there will still be some > > > slowdown, but not such an high one. Possibly on the guest make -j1 could > > > be better (it would be interesting). > > > > host # time make -j2 > > real 1m54.358s > > user 3m9.300s > > sys 0m18.910s > > Er, it seems that _I_ gave you a wrong suggestion - it is still using both > processor (though not optimally), so "time make -j1" on _both_ the host and > the guest is a fairer comparison. > > The confusion was born since on a uniprocessor machine it is usually suggested > to use make -j2. However, make -j2 on a dual core will use both processors. > > > guest # time make -j2 > > real 7m37.511s > > user 2m32.770s > > sys 0m23.200s > > > > guest # time make -j1 > > real 7m41.003s > > user 2m33.880s > > sys 0m23.230s > > > > :-( ''' > > : > > > Also, the user time is less on UML. The fact that total time is higher is > > > probably due to running with -j3 on a uniprocessor machine, and the fact > > > that the user time is less is probably due to using gcc 3.3 rather than 4 > > > (I seem to recall gcc 4 is slower in compilation than gcc 3). > > -- > Inform me of my mistakes, so I can add them to my list! > Paolo Giarrusso, aka Blaisorblade > http://www.user-mode-linux.org/~blaisorblade > Chiacchiera con i tuoi amici in tempo reale! > http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com > > |
From: Jonas M. <jmeyer@Alum.Dartmouth.ORG> - 2007-01-23 16:34:48
|
I just discovered a bug in UML. Under a vanilla edgy eft Ubuntu install as the host (with the linux-generic package installed for the kernel), and using linux2.6.16.29-bs2-32bit (from Blaisorblade) for the guest kernel, using the uml_mconsole HANDLE stop command can freeze the guest permanently. That is to say, i built a backup script which did the following: 1) stop the guest 2) mount the root_fs on the host 3) rsync stuff off of the root_fs (making no changes to the root_fs) 4) unmount the root_fs 5) issue the go command to the guest Some of the time it works just fine. However, out of 20 or so virtual machines, around 5 - 10 of them would freeze and need to be rebooted. They would still respond to pings, but they could neither be screened into, nor ssh, nor any other service would respond. Any ideas? I could install ssh on all the guests, and rsync directly off of them, but that is installing extra services that I'd rather not install and administrate. Jonas |
From: Antoine M. <an...@na...> - 2007-01-23 16:40:21
|
Between stop and go the filesystem is still mounted on the guest right? If so, you are screwing the filesystems by mounting them on the host: the mount command will run fixups on the (journaled?) filesystem. (You could try mounting read-only - but still, bad idea IMO) Antoine Jonas Meyer wrote: > I just discovered a bug in UML. Under a vanilla edgy eft Ubuntu install > as the host (with the linux-generic package installed for the kernel), > and using linux2.6.16.29-bs2-32bit (from Blaisorblade) for the guest > kernel, using the uml_mconsole HANDLE stop command can freeze the guest > permanently. That is to say, i built a backup script which did the > following: > > 1) stop the guest > 2) mount the root_fs on the host > 3) rsync stuff off of the root_fs (making no changes to the root_fs) > 4) unmount the root_fs > 5) issue the go command to the guest > > Some of the time it works just fine. However, out of 20 or so virtual > machines, around 5 - 10 of them would freeze and need to be rebooted. > They would still respond to pings, but they could neither be screened > into, nor ssh, nor any other service would respond. > > Any ideas? I could install ssh on all the guests, and rsync directly > off of them, but that is installing extra services that I'd rather not > install and administrate. > > Jonas > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > |
From: Chris L. <ch...@ex...> - 2007-01-23 16:44:15
|
On Tue, Jan 23, 2007 at 04:40:08PM +0000, Antoine Martin wrote: > Between stop and go the filesystem is still mounted on the guest right? > If so, you are screwing the filesystems by mounting them on the host: > the mount command will run fixups on the (journaled?) filesystem. > (You could try mounting read-only - but still, bad idea IMO) with journalled filesystems this is correct, though iirc there is a way to flush the journal for this type of application (well, specifically for mounting LVM snapshots to do backups, but it's semantically the same). but messing up the filesystem of a running machine shouldn't cause the effects described -- things should run, or more accurately fall messily apart, for a while after the event. -- ``It is hard to be pessimistic about an ageing population when your main source of employment is singing at funerals.'' (Reuben Thomas) |
From: Antoine M. <an...@na...> - 2007-01-23 16:48:50
|
Chris Lightfoot wrote: > On Tue, Jan 23, 2007 at 04:40:08PM +0000, Antoine Martin wrote: >> Between stop and go the filesystem is still mounted on the guest right? >> If so, you are screwing the filesystems by mounting them on the host: >> the mount command will run fixups on the (journaled?) filesystem. >> (You could try mounting read-only - but still, bad idea IMO) > > with journalled filesystems this is correct, though iirc > there is a way to flush the journal for this type of > application (well, specifically for mounting LVM snapshots > to do backups, but it's semantically the same). but > messing up the filesystem of a running machine shouldn't > cause the effects described -- things should run, or more > accurately fall messily apart, for a while after the > event. True. Jonas, is it really immediate in this case? Even if it its, it could still be a kernel bug (and not a UML bug). Which type of filesystem are you using? Antoine |
From: Jonas M. <jmeyer@Alum.Dartmouth.ORG> - 2007-01-23 17:01:42
|
It seems to be nearly instant, yes. If not instant, it is within 2-3 minutes. I am using ext3, so I should be mounting read-only. I wasn't, but somehow it doesn't seem like messing with the journal a little bit would screw up the system in this manner... I'll fix the read-only part and keep the list up to date. Jonas Antoine Martin wrote: > Chris Lightfoot wrote: >> On Tue, Jan 23, 2007 at 04:40:08PM +0000, Antoine Martin wrote: >>> Between stop and go the filesystem is still mounted on the guest right? >>> If so, you are screwing the filesystems by mounting them on the host: >>> the mount command will run fixups on the (journaled?) filesystem. >>> (You could try mounting read-only - but still, bad idea IMO) >> with journalled filesystems this is correct, though iirc >> there is a way to flush the journal for this type of >> application (well, specifically for mounting LVM snapshots >> to do backups, but it's semantically the same). but >> messing up the filesystem of a running machine shouldn't >> cause the effects described -- things should run, or more >> accurately fall messily apart, for a while after the >> event. > True. > Jonas, is it really immediate in this case? > > Even if it its, it could still be a kernel bug (and not a UML bug). > Which type of filesystem are you using? > > Antoine > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user |
From: Chris L. <ch...@ex...> - 2007-01-23 17:05:26
|
On Tue, Jan 23, 2007 at 12:00:17PM -0500, Jonas Meyer wrote: > It seems to be nearly instant, yes. If not instant, it is within 2-3 > minutes. I am using ext3, so I should be mounting read-only. I wasn't, > but somehow it doesn't seem like messing with the journal a little bit > would screw up the system in this manner... I'll fix the read-only part > and keep the list up to date. note that by default, ro mounts of ext3 can write to the filesystem. if you force a true ro mount (i.e. where the kernel may not write to the device) then the mount will fail if there are uncommitted journal entries. cf. http://www.mail-archive.com/tsl...@li.../msg04688.html -- Good judgement comes from experience. Experience comes from bad judgement. |
From: Jonas M. <jmeyer@Alum.Dartmouth.ORG> - 2007-01-23 17:19:05
|
Hmm... What is the preferred method of backup for a VM then? As I said, I'd rather not install ssh on every guest if I don't have to. Jonas Chris Lightfoot wrote: > On Tue, Jan 23, 2007 at 12:00:17PM -0500, Jonas Meyer wrote: >> It seems to be nearly instant, yes. If not instant, it is within 2-3 >> minutes. I am using ext3, so I should be mounting read-only. I wasn't, >> but somehow it doesn't seem like messing with the journal a little bit >> would screw up the system in this manner... I'll fix the read-only part >> and keep the list up to date. > > note that by default, ro mounts of ext3 can write to the > filesystem. if you force a true ro mount (i.e. where the > kernel may not write to the device) then the mount will > fail if there are uncommitted journal entries. cf. > http://www.mail-archive.com/tsl...@li.../msg04688.html > |
From: Chris L. <ch...@ex...> - 2007-01-23 17:23:27
|
On Tue, Jan 23, 2007 at 12:14:53PM -0500, Jonas Meyer wrote: > Hmm... What is the preferred method of backup for a VM then? As I > said, I'd rather not install ssh on every guest if I don't have to. depends how consistent a backup you need and what level of resource usage you can tolerate. e.g. you could pause the VM, copy the whole filesystem, and back up the result (accepting that you'll modify the copy when mounting it). or you could make a snapshot of the block device underlying the VMs' filesystems and then back that up however you want. etc. -- ``Conscience is the inner voice that warns us somebody may be looking.'' (Mencken) |
From: Brock, A. - N. <Ant...@or...> - 2007-01-23 17:26:30
|
I normally create the guest instances on an EVMS object. I then take a snapshot of the device after I've "frozen" and "flushed" the UML. Once I have the snapshot created, I then reactivate the guest (let it continue running) and deal with mounting and backing up the instance from the snapshot. Tony > -----Original Message----- > From: use...@li...=20 > [mailto:use...@li...]=20 > On Behalf Of Jonas Meyer > Sent: Tuesday, January 23, 2007 9:15 AM > To: use...@li... > Subject: Re: [uml-user] Bug in UML >=20 > Hmm... What is the preferred method of backup for a VM then? As I > said, I'd rather not install ssh on every guest if I don't have to. >=20 > Jonas >=20 > Chris Lightfoot wrote: > > On Tue, Jan 23, 2007 at 12:00:17PM -0500, Jonas Meyer wrote: > >> It seems to be nearly instant, yes. If not instant, it is=20 > within 2-3 > >> minutes. I am using ext3, so I should be mounting=20 > read-only. I wasn't, > >> but somehow it doesn't seem like messing with the journal=20 > a little bit > >> would screw up the system in this manner... I'll fix the=20 > read-only part > >> and keep the list up to date. > >=20 > > note that by default, ro mounts of ext3 can write to the > > filesystem. if you force a true ro mount (i.e. where the > > kernel may not write to the device) then the mount will > > fail if there are uncommitted journal entries. cf. > > =20 > http://www.mail-archive.com/tsl...@li.../msg0 > 4688.html > >=20 >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the=20 > chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDEV > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user >=20 |
From: Jonas M. <jmeyer@Alum.Dartmouth.ORG> - 2007-01-23 17:21:18
|
I'm not sure I follow, but I'll take your word for it. Is it your opinion, then, that if I upgrade to 2.6.19.2 it will fix my problem? Jonas Jyrki Jaakkola wrote: > From latest 2.6.19.2 kernel change log: > > "[PATCH] VM: Fix nasty and subtle race in shared mmap'ed page writeback > > The VM layer (on the face of it, fairly reasonably) expected that when > it does a ->writepage() call to the filesystem, it would write out the > full page at that point in time. Especially since it had earlier marked > the whole page dirty with "set_page_dirty()". > > But that isn't actually the case: ->writepage() does not actually write > a page, it writes the parts of the page that have been explicitly marked > dirty before, *and* that had not got written out for other reasons since > the last time we told it they were dirty. > > That last caveat is the important one. > > Which _most_ of the time ends up being the whole page (since we had > called "set_page_dirty()" on the page earlier), but if the filesystem > had done any dirty flushing of its own (for example, to honor some > internal write ordering guarantees), it might end up doing only a > partial page IO (or none at all) when ->writepage() is actually called. > > That is the correct thing in general (since we actually often _want_ > only the known-dirty parts of the page to be written out), but the > shared dirty page handling had implicitly forgotten about these details, > and had a number of cases where it was doing just the "->writepage()" > part, without telling the low-level filesystem that the whole page might > have been re-dirtied as part of being mapped writably into user space. > > Since most of the time the FS did actually write out the full page, we > didn't notice this for a loong time, and this needed some really odd > patterns to trigger. But it caused occasional corruption with rtorrent > and with the Debian "apt" database, because both use shared mmaps to > update the end result." > > This could be the cause for the problem. > > Jyrki Jaakkola > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user |
From: Jyrki J. <jy...@jj...> - 2007-01-23 17:27:25
|
Jonas Meyer wrote: > I'm not sure I follow, but I'll take your word for it. Is it your > opinion, then, that if I upgrade to 2.6.19.2 it will fix my problem? I'm not sure about it but that bug could be one of the possible causes. Jyrki Jaakkola |