I figured out that I had to do the following before I could free the loop device vgchange -an VolGroup00 kpartx -d /dev/loop0 losetup -d /dev/loop0 Girish On Mon, Jun 9, 2008 at 9:46 AM, <linux-lvm-request@redhat.com> wrote: > Send linux-lvm mailing list submissions to > linux-lvm@redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/linux-lvm > or, via email, send a message with subject or body 'help' to > linux-lvm-request@redhat.com > > You can reach the person managing the list at > linux-lvm-owner@redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of linux-lvm digest..." > > > Today's Topics: > > 1. Re: Re: Re: Loopback mount a disk image with lvm (Girish V) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 9 Jun 2008 09:46:29 -0400 > From: "Girish V" <girish.xen@gmail.com> > Subject: Re: Re: Re: Loopback mount a disk image with lvm > To: linux-lvm@redhat.com > Message-ID: > <2122f0920806090646h46bb29cds76fb957a2b8e0cbe@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Incidentally, how do I free the loop (/dev/loop0) associated with > disk.img. I tried "sudo losetup -d /dev/loop0", but I get the error > message "ioctl: LOOP_CLR_FD: Device or resource busy". > > I tried looking at mount, ps, top etc - but the disk.img associated > with loop0, was not being used. > > Any ideas? > Thanks > > On Mon, Jun 9, 2008 at 8:59 AM, <linux-lvm-request@redhat.com> wrote: >> Send linux-lvm mailing list submissions to >> linux-lvm@redhat.com >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.redhat.com/mailman/listinfo/linux-lvm >> or, via email, send a message with subject or body 'help' to >> linux-lvm-request@redhat.com >> >> You can reach the person managing the list at >> linux-lvm-owner@redhat.com >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of linux-lvm digest..." >> >> >> Today's Topics: >> >> 1. Re: Performance tunning on LVM2 (Heinz Mauelshagen) >> 2. Re: Re: Loopback mount a disk image with lvm (Girish) (Girish V) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 9 Jun 2008 13:43:55 +0200 >> From: Heinz Mauelshagen <mauelshagen@redhat.com> >> Subject: Re: Performance tunning on LVM2 >> To: Antony MARTINEAU <Antony.MARTINEAU@lippi.fr> >> Cc: LVM general discussion and development <linux-lvm@redhat.com>, >> mauelshagen@redhat.com >> Message-ID: <20080609114355.GB5507@redhat.com> >> Content-Type: text/plain; charset=us-ascii >> >> On Mon, Jun 09, 2008 at 12:06:19PM +0200, Antony MARTINEAU wrote: >>> Thanks for your answer... >>> But my test show that it is, the LVM2 software the probleme... >> >> device-mapper snapshot target actually. >> >>> >>> Because even whith 3 writing test at the same time on 3 LV which are on >>> the same VG and the same PV, the performance are better than one LV whith >>> only one snapshot... >> >> Sure, the write patterns for snapshots go sequentially to the disk >> (i.e. read from origin, write to COW store, write to origin, ...). >> >>> >>> Look this test: >>> >>> suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=10M count=150 >>> 150+0 records in >>> 150+0 records out >>> 1572864000 bytes (1.6 GB) copied, 27.9422 seconds, 56.3 MB/s >>> >>> suse2:~ # dd if=/dev/zero of=/dev/vg0/test2 bs=10M count=150 >>> 150+0 records in >>> 150+0 records out >>> 1572864000 bytes (1.6 GB) copied, 33.2836 seconds, 47.3 MB/s >>> >>> suse2:~ # dd if=/dev/zero of=/dev/vg0/test3 bs=10M count=150 >>> 150+0 records in >>> 150+0 records out >>> 1572864000 bytes (1.6 GB) copied, 33.784 seconds, 46.6 MB/s >>> >>> With 3 writing test AT THE SAME TIME , the average is better that one >>> writing test on one LV whith one snap >>> >>> Look, >>> >>> suse2:~ # lvcreate -s -L2G -ntest.snap /dev/vg0/test >>> Logical volume "test.snap" created >>> >>> suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=10M count=150 >>> 150+0 records in >>> 150+0 records out >>> 1572864000 bytes (1.6 GB) copied, 382.315 seconds, 4.1 MB/s >>> >>> It is disastrous... >>> >>> I think dd is a good test... >> >> It's an extreme test like I tried to point out. >> >> Like already mentioned: you gotta put the COW store on a seperate PV >> after adding one to your vg0 (say /dev/sdb1). >> >> E.g.: >> pvcreate /dev/sdb1 >> vgextend vg0 /dev/sdb1 >> lvcreate -s -L2G -ntest.snap /dev/vg0/test /dev/sdb1 >> >> Heinz >> >> >>> >>> >>> Cordialement, >>> >>> >>> >>> MARTINEAU >>> Antony >>> Service informatique >>> Assistant informatique >>> LIPPI Management >>> La Fouillouse >>> 16440 Mouthiers sur Boheme >>> Tel.: 05.45.67.34.35 >>> Courriel: antony.martineau@lippi.fr >>> http://www.lippi.fr >>> >>> >>> >>> >>> De : >>> Heinz Mauelshagen <mauelshagen@redhat.com> >>> Pour : >>> LVM general discussion and development <linux-lvm@redhat.com> >>> Date: >>> 09/06/2008 11:46 >>> Objet : >>> Re: Performance tunning on LVM2 >>> >>> >>> >>> On Fri, Jun 06, 2008 at 08:03:51AM -0700, Larry Dickson wrote: >>> > A (linear) volume group made of two physical volumes consists of one PV >>> > followed by the other, rather like a "Raid-Linear". If you size the >>> > origin logical volume right, you can get one LV (the origin) to fall on >>> one >>> > disk, and force the snapshot to land on the other disk. This eliminates >>> > back-and-forth seeking to the COW. Whether it solves your problem will >>> > depend on how smart the driver is about the read-before-write activity >>> on >>> > the origin volume. >>> > >>> > Other members of the list may have more experience on this. Comments? >>> >>> If I read correctly, Antony just has *ONE* PV. >>> >>> So no matter what, he has to add another to allow for snapshot COW >>> store allocation on that other PV, distinct from the one holding >>> the origin(s). Presumably there's no other bottleneck aside from the >>> disk, that'll do better. >>> >>> Keep in mind, that unless you've got streaming writes, the performance >>> won't drop as much as in the (artificial) dd test below. >>> >>> FYI: With the current snapshot implementation, multiple snapshots per >>> single >>> origin will throttle write performance because of write duplication >>> to all per snapshot COW stores. >>> >>> Heinz >>> >>> > >>> > Larry >>> > >>> > On 6/6/08, Antony MARTINEAU <Antony.MARTINEAU@lippi.fr> wrote: >>> > > >>> > > >>> > > The volume group vg0 is the raid0 of two disk (SAS 15000rpm 300G0) >>> > > I have only this raid on the server >>> > > >>> > > But i don't understand, imagine i make a volume group ou of this >>> raid0. It >>> > > is no possible to snapshot the original volume, am i wrong? >>> > > >>> > > If i make a new VG on another disks, For exemple /dev/vg1/ >>> > > LVM don't permit to store a snaphot on a different VG than the origin >>> > > volum. >>> > > >>> > > for exemple /dev/vg0/test cant be snapshoting on /dev/vg1/test.snap >>> > > >>> > > LV test and LV test.snap must be on the same volume, am i wrong ???? >>> so it >>> > > is impossible to store snapshot on another disk.... >>> > > >>> > > >>> > > Cordialement, >>> > > >>> > > *MARTINEAU >>> > > Antony* >>> > > Service informatique >>> > > Assistant informatique >>> > > LIPPI Management La Fouillouse >>> > > 16440 Mouthiers sur Boheme >>> > > Tel.: 05.45.67.34.35 >>> > > Courriel: *antony.martineau@lippi.fr* <antony.martineau@lippi.fr>* >>> > > **http://www.lippi.fr* <http://www.lippi.fr/> >>> > > >>> > > >>> > > >>> > > De : "Larry Dickson" <ldickson@cuttedge.com> Pour : "LVM general >>> > > discussion and development" <linux-lvm@redhat.com> Date: 06/06/2008 >>> 16:19 Objet >>> > > : Re: Performance tunning on LVM2 >>> > > ------------------------------ >>> > > >>> > > >>> > > >>> > > This looks like the result of excessive seeking. Are origin volume and >>> > > snapshot both on the same physical drive? Is it possible to make a >>> volume >>> > > group out of two drives, and arrange things so that origin volume and >>> > > snapshot are hitting different disks? >>> > > >>> > > Larry Dickson >>> > > Cutting Edge Networked Storage >>> > > >>> > > On 6/6/08, *Antony MARTINEAU* >>> <*Antony.MARTINEAU@lippi.fr*<Antony.MARTINEAU@lippi.fr>> >>> > > wrote: >>> > > >>> > > Hello, >>> > > My configuration: >>> > > Server DELL 2860 Intel(R) Xeon(R) CPU X3230 @ 2.66GHz (Quad Core) >>> > > 8GB of memory >>> > > 2 x SAS 15000 300G0 RAID 0 hardware >>> > > SLES 10 SP2 >>> > > Kernel 2.6.16.60-0.21-xen >>> > > >>> > > i have one volume group vg0 ( whith one PV, the two disks in raid0) >>> whith >>> > > many lvm >>> > > I am very surprise about LVM2 performance when a snapshot is done. >>> > > Write speed on the Original volume is very bad when a snaphot is >>> active... >>> > > >>> > > For exemple: >>> > > * >>> > > Speed on /dev/vg0/test when there is NO snapshot :* >>> > > >>> > > suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=2M count=400 >>> > > 400+0 records in >>> > > 400+0 records out >>> > > 838860800 bytes (839 MB) copied, 6.42741 seconds, 131 MB/s >>> > > * >>> > > Speed on /dev/vg0/test when there is one snapshot of this original >>> volume : >>> > > * >>> > > >>> > > suse2:~ # lvremove --force /dev/vg0/test3.snap >>> > > Logical volume "test3.snap" successfully removed >>> > > suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=2M count=400 >>> > > 400+0 records in >>> > > 400+0 records out >>> > > 838860800 bytes (839 MB) copied, 6.42741 seconds, 131 MB/s >>> > > suse2:~ # lvcreate -s -L1G -ntest.snap /dev/vg0/test >>> > > Logical volume "test.snap" created >>> > > suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=2M count=400 >>> > > 400+0 records in >>> > > 400+0 records out >>> > > 838860800 bytes (839 MB) copied, 204.862 seconds, 4.1 MB/s >>> > > >>> > > * >>> > > Speed on /dev/vg0/test when there is 2 snapshots of this original >>> volume : >>> > > * >>> > > >>> > > suse2:~ # lvcreate -s -L1G -ntest1.snap /dev/vg0/test >>> > > Logical volume "test1.snap" created >>> > > suse2:~ # lvcreate -s -L1G -ntest2.snap /dev/vg0/test >>> > > Logical volume "test2.snap" created >>> > > suse2:~ # lvremove /dev/vg0/test2.snap >>> > > Do you really want to remove active logical volume "test2.snap"? >>> [y/n]: y >>> > > Logical volume "test2.snap" successfully removed >>> > > suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=2M count=400 >>> > > 400+0 records in >>> > > 400+0 records out >>> > > 838860800 bytes (839 MB) copied, 270.928 seconds, 3.1 MB/s >>> > > >>> > > >>> > > Do you know some elements about tunning performance?,? >>> > > >>> > > Performances are disastrous when a snaphot is active >>> > > Could you give your speed result? and your amelioration?? >>> > > >>> > > ps:Results are the same whithout Kernel Xen and whith a kernel more >>> recent >>> > > (*2.6.24.2* <http://2.6.24.2/>) Cordialement, >>> > > *MARTINEAU >>> > > Antony* >>> > > Service informatique >>> > > Assistant informatique >>> > > LIPPI Management La Fouillouse >>> > > 16440 Mouthiers sur Boheme >>> > > Tel.: 05.45.67.34.35 >>> > > Courriel: *antony.martineau@lippi.fr* <antony.martineau@lippi.fr>* >>> > > **http://www.lippi.fr* <http://www.lippi.fr/> >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > Ce message et toutes les pieces jointes sont etablis a l'attention >>> > > exclusive de ses destinataires et sont strictement confidentiels. >>> *Pour en >>> > > savoir plus cliquer ici* <http://www.lippi.fr/disclaimer.php> >>> > > >>> > > This message and any attachments are confidential to the ordinary user >>> of >>> > > the e-mail address to which it was addressed and may also be >>> privileged. *More >>> > > information* <http://www.lippi.fr/disclaimer.php> >>> > > >>> > > >>> > > _______________________________________________ >>> > > linux-lvm mailing list* >>> > > **linux-lvm@redhat.com* <linux-lvm@redhat.com>* >>> > > **https://www.redhat.com/mailman/listinfo/linux-lvm*< >>> https://www.redhat.com/mailman/listinfo/linux-lvm> >>> > > read the LVM HOW-TO at *http://tldp.org/HOWTO/LVM-HOWTO/*< >>> http://tldp.org/HOWTO/LVM-HOWTO/> >>> > > _______________________________________________ >>> > > linux-lvm mailing list >>> > > linux-lvm@redhat.com >>> > > https://www.redhat.com/mailman/listinfo/linux-lvm >>> > > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > Ce message et toutes les pieces jointes sont etablis a l'attention >>> > > exclusive de ses destinataires et sont strictement confidentiels. >>> *Pour en >>> > > savoir plus cliquer ici* <http://www.lippi.fr/disclaimer.php> >>> > > >>> > > This message and any attachments are confidential to the ordinary user >>> of >>> > > the e-mail address to which it was addressed and may also be >>> privileged. *More >>> > > information* <http://www.lippi.fr/disclaimer.php> >>> > > >>> > > >>> > > _______________________________________________ >>> > > linux-lvm mailing list >>> > > linux-lvm@redhat.com >>> > > https://www.redhat.com/mailman/listinfo/linux-lvm >>> > > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ >>> > > >>> >>> >>> >>> >>> > _______________________________________________ >>> > linux-lvm mailing list >>> > linux-lvm@redhat.com >>> > https://www.redhat.com/mailman/listinfo/linux-lvm >>> > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ >>> >>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> >>> Heinz Mauelshagen Red Hat GmbH >>> Consulting Development Engineer Am Sonnenhang 11 >>> Storage Development 56242 Marienrachdorf >>> Germany >>> Mauelshagen@RedHat.com PHONE +49 171 7803392 >>> FAX +49 2626 924446 >>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> >>> _______________________________________________ >>> linux-lvm mailing list >>> linux-lvm@redhat.com >>> https://www.redhat.com/mailman/listinfo/linux-lvm >>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Ce message et toutes les pieces jointes sont etablis a l'attention >>> exclusive de ses destinataires et sont strictement confidentiels. Pour en >>> savoir plus cliquer ici >>> >>> This message and any attachments are confidential to the ordinary user of >>> the e-mail address to which it was addressed and may also be privileged. >>> More information >> >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> >> Heinz Mauelshagen Red Hat GmbH >> Consulting Development Engineer Am Sonnenhang 11 >> Storage Development 56242 Marienrachdorf >> Germany >> Mauelshagen@RedHat.com PHONE +49 171 7803392 >> FAX +49 2626 924446 >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 9 Jun 2008 08:58:17 -0400 >> From: "Girish V" <girish.xen@gmail.com> >> Subject: Re: Re: Loopback mount a disk image with lvm >> (Girish) >> To: linux-lvm@redhat.com >> Message-ID: >> <2122f0920806090558j180263f8uadd209c608220e84@mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Thanks Dave, >> This worked like a charm. >> Girish >> >> >> On Mon, Jun 9, 2008 at 6:10 AM, <linux-lvm-request@redhat.com> wrote: >>> Send linux-lvm mailing list submissions to >>> linux-lvm@redhat.com >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.redhat.com/mailman/listinfo/linux-lvm >>> or, via email, send a message with subject or body 'help' to >>> linux-lvm-request@redhat.com >>> >>> You can reach the person managing the list at >>> linux-lvm-owner@redhat.com >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of linux-lvm digest..." >>> >>> >>> Today's Topics: >>> >>> 1. striping question (Mag Gam) >>> 2. Loopback mount a disk image with lvm (Girish V) >>> 3. Re: Loopback mount a disk image with lvm (David Robinson) >>> 4. Re: Performance tunning on LVM2 (Heinz Mauelshagen) >>> 5. Re: Performance tunning on LVM2 (Antony MARTINEAU) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Sat, 7 Jun 2008 11:39:09 -0400 >>> From: "Mag Gam" <magawake@gmail.com> >>> Subject: striping question >>> To: linux-lvm@redhat.com >>> Message-ID: >>> <1cbd6f830806070839l436b0b4ai99d3c4264e896ea6@mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> If I am using x RAID 5 volumes and create PVs. Once I create the LVs is it a >>> good idea to stripe them? If so, what is a valid stripe size? >>> >>> I am looking for performance BTW. >>> >>> >>> TIA >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: https://www.redhat.com/archives/linux-lvm/attachments/20080607/69fbc84c/attachment.html >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Sun, 8 Jun 2008 18:23:23 -0400 >>> From: "Girish V" <girish.xen@gmail.com> >>> Subject: Loopback mount a disk image with lvm >>> To: linux-lvm@redhat.com >>> Message-ID: >>> <2122f0920806081523w7a7ce274q9707992948f6e1b4@mail.gmail.com> >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Hello, >>> >>> I have a disk.img (a disk image file, raw format) with the following "fdisk -l" >>> >>> Device Boot Start End Blocks Id System >>> disk.img1 * 1 13 104391 83 Linux >>> disk.img2 14 2491 19904535 8e Linux LVM >>> >>> Now I can loopback mount the first bartition using >>> "mount -o loop,offset=32256 disk.img /mnt". >>> >>> I need to mount the second partition. If the secoond partition had >>> been an ext3 partition, I would have loopback mounted it as >>> "mount -o loop,offset=$((255*63*512*13) disk.img /mnt", but when I try >>> that, I get >>> mount: unknown filesystem type 'LVM2_member' >>> >>> Any help is greatly appreciated. >>> >>> Thanks. >>> >>> >>> >>> ------------------------------ >>> >>> Message: 3 >>> Date: Mon, 9 Jun 2008 10:52:54 +1000 >>> From: "David Robinson" <zxvdr.au@gmail.com> >>> Subject: Re: Loopback mount a disk image with lvm >>> To: "LVM general discussion and development" <linux-lvm@redhat.com> >>> Message-ID: >>> <b072968d0806081752s79f32e66h4c6d7de1b42094a0@mail.gmail.com> >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> On Mon, Jun 9, 2008 at 8:23 AM, Girish V <girish.xen@gmail.com> wrote: >>>> Hello, >>>> >>>> I have a disk.img (a disk image file, raw format) with the following "fdisk -l" >>>> >>>> Device Boot Start End Blocks Id System >>>> disk.img1 * 1 13 104391 83 Linux >>>> disk.img2 14 2491 19904535 8e Linux LVM >>>> >>>> Now I can loopback mount the first bartition using >>>> "mount -o loop,offset=32256 disk.img /mnt". >>>> >>>> I need to mount the second partition. If the secoond partition had >>>> been an ext3 partition, I would have loopback mounted it as >>>> "mount -o loop,offset=$((255*63*512*13) disk.img /mnt", but when I try >>>> that, I get >>>> mount: unknown filesystem type 'LVM2_member' >>>> >>>> Any help is greatly appreciated. >>> >>> losetup /dev/loop0 disk.img >>> kpartx -a /dev/loop0 >>> >>> Then to mount the first partition: >>> >>> mount /dev/mapper/loop0p1 /mnt >>> >>> Or to activate the volume group then mount the logical volume: >>> >>> vgscan >>> vgchange -ay vg >>> mount /dev/vg/lv /mnt >>> >>> Hope that helps. >>> >>> --Dave >>> >>> >>> >>> ------------------------------ >>> >>> Message: 4 >>> Date: Mon, 9 Jun 2008 11:44:53 +0200 >>> From: Heinz Mauelshagen <mauelshagen@redhat.com> >>> Subject: Re: Performance tunning on LVM2 >>> To: LVM general discussion and development <linux-lvm@redhat.com> >>> Message-ID: <20080609094453.GA5507@redhat.com> >>> Content-Type: text/plain; charset=us-ascii >>> >>> On Fri, Jun 06, 2008 at 08:03:51AM -0700, Larry Dickson wrote: >>>> A (linear) volume group made of two physical volumes consists of one PV >>>> followed by the other, rather like a "Raid-Linear". If you size the >>>> origin logical volume right, you can get one LV (the origin) to fall on one >>>> disk, and force the snapshot to land on the other disk. This eliminates >>>> back-and-forth seeking to the COW. Whether it solves your problem will >>>> depend on how smart the driver is about the read-before-write activity on >>>> the origin volume. >>>> >>>> Other members of the list may have more experience on this. Comments? >>> >>> If I read correctly, Antony just has *ONE* PV. >>> >>> So no matter what, he has to add another to allow for snapshot COW >>> store allocation on that other PV, distinct from the one holding >>> the origin(s). Presumably there's no other bottleneck aside from the >>> disk, that'll do better. >>> >>> Keep in mind, that unless you've got streaming writes, the performance >>> won't drop as much as in the (artificial) dd test below. >>> >>> FYI: With the current snapshot implementation, multiple snapshots per single >>> origin will throttle write performance because of write duplication >>> to all per snapshot COW stores. >>> >>> Heinz >>> >>>> >>>> Larry >>>> >>>> On 6/6/08, Antony MARTINEAU <Antony.MARTINEAU@lippi.fr> wrote: >>>> > >>>> > >>>> > The volume group vg0 is the raid0 of two disk (SAS 15000rpm 300G0) >>>> > I have only this raid on the server >>>> > >>>> > But i don't understand, imagine i make a volume group ou of this raid0. It >>>> > is no possible to snapshot the original volume, am i wrong? >>>> > >>>> > If i make a new VG on another disks, For exemple /dev/vg1/ >>>> > LVM don't permit to store a snaphot on a different VG than the origin >>>> > volum. >>>> > >>>> > for exemple /dev/vg0/test cant be snapshoting on /dev/vg1/test.snap >>>> > >>>> > LV test and LV test.snap must be on the same volume, am i wrong ???? so it >>>> > is impossible to store snapshot on another disk.... >>>> > >>>> > >>>> > Cordialement, >>>> > >>>> > *MARTINEAU >>>> > Antony* >>>> > Service informatique >>>> > Assistant informatique >>>> > LIPPI Management La Fouillouse >>>> > 16440 Mouthiers sur Boheme >>>> > Tel.: 05.45.67.34.35 >>>> > Courriel: *antony.martineau@lippi.fr* <antony.martineau@lippi.fr>* >>>> > **http://www.lippi.fr* <http://www.lippi.fr/> >>>> > >>>> > >>>> > >>>> > De : "Larry Dickson" <ldickson@cuttedge.com> Pour : "LVM general >>>> > discussion and development" <linux-lvm@redhat.com> Date: 06/06/2008 16:19 Objet >>>> > : Re: Performance tunning on LVM2 >>>> > ------------------------------ >>>> > >>>> > >>>> > >>>> > This looks like the result of excessive seeking. Are origin volume and >>>> > snapshot both on the same physical drive? Is it possible to make a volume >>>> > group out of two drives, and arrange things so that origin volume and >>>> > snapshot are hitting different disks? >>>> > >>>> > Larry Dickson >>>> > Cutting Edge Networked Storage >>>> > >>>> > On 6/6/08, *Antony MARTINEAU* <*Antony.MARTINEAU@lippi.fr*<Antony.MARTINEAU@lippi.fr>> >>>> > wrote: >>>> > >>>> > Hello, >>>> > My configuration: >>>> > Server DELL 2860 Intel(R) Xeon(R) CPU X3230 @ 2.66GHz (Quad Core) >>>> > 8GB of memory >>>> > 2 x SAS 15000 300G0 RAID 0 hardware >>>> > SLES 10 SP2 >>>> > Kernel 2.6.16.60-0.21-xen >>>> > >>>> > i have one volume group vg0 ( whith one PV, the two disks in raid0) whith >>>> > many lvm >>>> > I am very surprise about LVM2 performance when a snapshot is done. >>>> > Write speed on the Original volume is very bad when a snaphot is active... >>>> > >>>> > For exemple: >>>> > * >>>> > Speed on /dev/vg0/test when there is NO snapshot :* >>>> > >>>> > suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=2M count=400 >>>> > 400+0 records in >>>> > 400+0 records out >>>> > 838860800 bytes (839 MB) copied, 6.42741 seconds, 131 MB/s >>>> > * >>>> > Speed on /dev/vg0/test when there is one snapshot of this original volume : >>>> > * >>>> > >>>> > suse2:~ # lvremove --force /dev/vg0/test3.snap >>>> > Logical volume "test3.snap" successfully removed >>>> > suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=2M count=400 >>>> > 400+0 records in >>>> > 400+0 records out >>>> > 838860800 bytes (839 MB) copied, 6.42741 seconds, 131 MB/s >>>> > suse2:~ # lvcreate -s -L1G -ntest.snap /dev/vg0/test >>>> > Logical volume "test.snap" created >>>> > suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=2M count=400 >>>> > 400+0 records in >>>> > 400+0 records out >>>> > 838860800 bytes (839 MB) copied, 204.862 seconds, 4.1 MB/s >>>> > >>>> > * >>>> > Speed on /dev/vg0/test when there is 2 snapshots of this original volume : >>>> > * >>>> > >>>> > suse2:~ # lvcreate -s -L1G -ntest1.snap /dev/vg0/test >>>> > Logical volume "test1.snap" created >>>> > suse2:~ # lvcreate -s -L1G -ntest2.snap /dev/vg0/test >>>> > Logical volume "test2.snap" created >>>> > suse2:~ # lvremove /dev/vg0/test2.snap >>>> > Do you really want to remove active logical volume "test2.snap"? [y/n]: y >>>> > Logical volume "test2.snap" successfully removed >>>> > suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=2M count=400 >>>> > 400+0 records in >>>> > 400+0 records out >>>> > 838860800 bytes (839 MB) copied, 270.928 seconds, 3.1 MB/s >>>> > >>>> > >>>> > Do you know some elements about tunning performance?,? >>>> > >>>> > Performances are disastrous when a snaphot is active >>>> > Could you give your speed result? and your amelioration?? >>>> > >>>> > ps:Results are the same whithout Kernel Xen and whith a kernel more recent >>>> > (*2.6.24.2* <http://2.6.24.2/>) Cordialement, >>>> > *MARTINEAU >>>> > Antony* >>>> > Service informatique >>>> > Assistant informatique >>>> > LIPPI Management La Fouillouse >>>> > 16440 Mouthiers sur Boheme >>>> > Tel.: 05.45.67.34.35 >>>> > Courriel: *antony.martineau@lippi.fr* <antony.martineau@lippi.fr>* >>>> > **http://www.lippi.fr* <http://www.lippi.fr/> >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > Ce message et toutes les pieces jointes sont etablis a l'attention >>>> > exclusive de ses destinataires et sont strictement confidentiels. *Pour en >>>> > savoir plus cliquer ici* <http://www.lippi.fr/disclaimer.php> >>>> > >>>> > This message and any attachments are confidential to the ordinary user of >>>> > the e-mail address to which it was addressed and may also be privileged. *More >>>> > information* <http://www.lippi.fr/disclaimer.php> >>>> > >>>> > >>>> > _______________________________________________ >>>> > linux-lvm mailing list* >>>> > **linux-lvm@redhat.com* <linux-lvm@redhat.com>* >>>> > **https://www.redhat.com/mailman/listinfo/linux-lvm*<https://www.redhat.com/mailman/listinfo/linux-lvm> >>>> > read the LVM HOW-TO at *http://tldp.org/HOWTO/LVM-HOWTO/*<http://tldp.org/HOWTO/LVM-HOWTO/> >>>> > _______________________________________________ >>>> > linux-lvm mailing list >>>> > linux-lvm@redhat.com >>>> > https://www.redhat.com/mailman/listinfo/linux-lvm >>>> > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > Ce message et toutes les pieces jointes sont etablis a l'attention >>>> > exclusive de ses destinataires et sont strictement confidentiels. *Pour en >>>> > savoir plus cliquer ici* <http://www.lippi.fr/disclaimer.php> >>>> > >>>> > This message and any attachments are confidential to the ordinary user of >>>> > the e-mail address to which it was addressed and may also be privileged. *More >>>> > information* <http://www.lippi.fr/disclaimer.php> >>>> > >>>> > >>>> > _______________________________________________ >>>> > linux-lvm mailing list >>>> > linux-lvm@redhat.com >>>> > https://www.redhat.com/mailman/listinfo/linux-lvm >>>> > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ >>>> > >>> >>> >>> >>> >>>> _______________________________________________ >>>> linux-lvm mailing list >>>> linux-lvm@redhat.com >>>> https://www.redhat.com/mailman/listinfo/linux-lvm >>>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ >>> >>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> >>> Heinz Mauelshagen Red Hat GmbH >>> Consulting Development Engineer Am Sonnenhang 11 >>> Storage Development 56242 Marienrachdorf >>> Germany >>> Mauelshagen@RedHat.com PHONE +49 171 7803392 >>> FAX +49 2626 924446 >>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> >>> >>> >>> ------------------------------ >>> >>> Message: 5 >>> Date: Mon, 9 Jun 2008 12:06:19 +0200 >>> From: Antony MARTINEAU <Antony.MARTINEAU@lippi.fr> >>> Subject: Re: Performance tunning on LVM2 >>> To: mauelshagen@redhat.com, LVM general discussion and development >>> <linux-lvm@redhat.com> >>> Message-ID: >>> <OF8D53F89C.8A8CDA30-ONC1257463.00362B8A-C1257463.00377B47@lippi.fr> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> Skipped content of type multipart/alternative-------------- next part -------------- >>> A non-text attachment was scrubbed... >>> Name: not available >>> Type: image/gif >>> Size: 5552 bytes >>> Desc: not available >>> Url : https://www.redhat.com/archives/linux-lvm/attachments/20080609/c6399248/attachment.gif >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> linux-lvm mailing list >>> linux-lvm@redhat.com >>> https://www.redhat.com/mailman/listinfo/linux-lvm >>> >>> End of linux-lvm Digest, Vol 52, Issue 9 >>> **************************************** >>> >> >> >> >> ------------------------------ >> >> _______________________________________________ >> linux-lvm mailing list >> linux-lvm@redhat.com >> https://www.redhat.com/mailman/listinfo/linux-lvm >> >> End of linux-lvm Digest, Vol 52, Issue 10 >> ***************************************** >> > > > > ------------------------------ > > _______________________________________________ > linux-lvm mailing list > linux-lvm@redhat.com > https://www.redhat.com/mailman/listinfo/linux-lvm > > End of linux-lvm Digest, Vol 52, Issue 11 > ***************************************** > _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
