11 a.m.
lvcreate -s -n snap -l 10 /dev/V0/fc2
/dev/V0/fc2 is the root file system for my FC2 machine. I ran the above
command to make a snapshot of it named /dev/mapper/snap and now all access to
the root FS is blocking. I had "less" running before this and I can still
scroll. I expect that "-l 10" is enough as my PE size is 16M and I don't
expect to make more than 160M of changes before the backup is complete.
Did I do something wrong or is this an indication of a kernel bug in LVM?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
3:05 a.m.
On Aug 11, 2004, Russell Coker <russell(a)coker.com.au> wrote:
Did I do something wrong or is this an indication of a kernel bug in
LVM?
It is a bug. LVM support in the FC2 kernels has been very poor,
except for the trivial stuff like creating LVs and using them.
Snapshots and pvmove were the most important features I've missed in
the device-mapper-based implementation of LVM.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
5:17 a.m.
On Thu, 2004-08-12 at 05:05 -0300, Alexandre Oliva wrote:
On Aug 11, 2004, Russell Coker <russell(a)coker.com.au> wrote:
> Did I do something wrong or is this an indication of a kernel bug in LVM?
It is a bug. LVM support in the FC2 kernels has been very poor,
except for the trivial stuff like creating LVs and using them.
Snapshots and pvmove were the most important features I've missed in
the device-mapper-based implementation of LVM.
So it wasn't my bad when pvmove didn't work!
Răzvan Corneliu VILT e-mail:razvan.vilt@linux360.ro
GPG:http://d3vi1.linux360.ro/public-keys/ www: http://d3vi1.linux360.ro/
8:09 a.m.
On Thu, 12 Aug 2004 02:00, Russell Coker <russell(a)coker.com.au> wrote:
lvcreate -s -n snap -l 10 /dev/V0/fc2
/dev/V0/fc2 is the root file system for my FC2 machine. I ran the above
command to make a snapshot of it named /dev/mapper/snap and now all access
to the root FS is blocking. I had "less" running before this and I can
still scroll. I expect that "-l 10" is enough as my PE size is 16M and I
don't expect to make more than 160M of changes before the backup is
complete.
Did I do something wrong or is this an indication of a kernel bug in LVM?
I just tried rebooted that machine. The LVM setup seems mangled and it
doesn't boot successfully.
On #lvm on irc.freenode.net I was told that the kernels in Fedora don't yet
support snap-shot which is the cause of the problem. I have been told that
the lvm utility programs in FC3T1 correctly detect this (and presumably don't
break the system).
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
7:17 a.m.
On Thu, Aug 12, 2004 at 11:09:25PM +1000, Russell Coker wrote:
> Did I do something wrong or is this an indication of a kernel
bug in LVM?
Which kernel, the FC2 errata kernel? Probably just a problem with the
userspace side; grab the RPMS from Rawhide.
I've been playing with snapshots since kernel-2.6.7-1.471 (i.e.,
2.6.7-bk18) on both FC2 and FC1, using packages from Rawhide. I have
another machine running 2.6.7-1.492 (2.6.7-rc1) that also seems to work,
though it hasn't been tested much. (Both kernels patched and rebuilt
without 4G/4G.)
Snapshot performance was not particularly good (on soft-RAID1), but I ran
bonnie++ on an 8GB filesystem with a snapshot in place, and it survived,
even while running cpio -o > /dev/null on the snapshot. I need to find
time to roll my patches forward, retest, and look at the tunables.
I just tried rebooted that machine. The LVM setup seems mangled and
it
doesn't boot successfully.
I encountered a "gotcha" when using snapshots (or DM mirror): if using an
initrd, one needs to place those modules (dm-snapshot, dm-mirror)
in the initrd, otherwise LVM2 won't activate the LVs when you reboot.
Alexandre, where should this config info live? Historically, we had the
loop stuff in /etc/fstab; thankfully, dependence on loop is going away.
Regards,
Bill Rugolsky
3:54 a.m.
On Aug 13, 2004, "Bill Rugolsky Jr." <brugolsky(a)telemetry-investments.com>
wrote:
I encountered a "gotcha" when using snapshots (or DM
mirror): if using an
initrd, one needs to place those modules (dm-snapshot, dm-mirror)
in the initrd, otherwise LVM2 won't activate the LVs when you reboot.
Ugh.
Alexandre, where should this config info live?
Err... I think mkinitrd should perhaps auto-detect the need for such
modules somehow. Any ideas on how to do that?
Alternatively, we could just add them unconditionally if LVM is
enabled, which would presumably enable the system to reboot even if
major changes took place in the VG, that would require initrd to be
re-created otherwise.
Especially considering that pvmove requires mirroring support now, I
feel sympathetic to the idea of having dm-mirror unconditionally, such
that, if you happen to reboot in the middle of a pvmove, you don't end
up in big trouble.
Talking of dm-mirror, I haven't kept track of it; does anyone know how
it guarantees atomic writes to the replicas of an extent? Does it
resync the whole device in case there's say loss of power or a crash
when the devices are out of sync, like raid 1, or are in-sync bits
maintained on a per-extent basis? Or does it just punt at it?
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
9:22 a.m.
Once upon a time, Alexandre Oliva <aoliva(a)redhat.com> said:
Especially considering that pvmove requires mirroring support now, I
feel sympathetic to the idea of having dm-mirror unconditionally, such
that, if you happen to reboot in the middle of a pvmove, you don't end
up in big trouble.
For the same reason, I'd suggest dm-snapshot also be unconditionally
included. I use snapshots to get consistent backups; if the system were
rebooted during backup (while the snapshot of / exists), I guess
dm-snapshot is required, right?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:01 p.m.
On Aug 18, 2004, Chris Adams <cmadams(a)hiwaay.net> wrote:
For the same reason, I'd suggest dm-snapshot also be
unconditionally
included. I use snapshots to get consistent backups; if the system were
rebooted during backup (while the snapshot of / exists), I guess
dm-snapshot is required, right?
Maybe not. Since it's a separate LV, it's perfectly possible that, if
dm-snapshot is not available in the initrd vgscan, you won't get that
LV active, but will for the rest; later on, after the root fs is
mounted read-write, vgscan runs again, and the module is available, so
you get the snapshot volume up and running.
This is unlike dm-mirror (assuming pvmove actually uses it), since it
modifies existing volumes (e.g., the one holding the rootfs), you may
need dm-mirror early in order to boot up.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
10:22 a.m.
On Wed, Aug 18, 2004 at 05:54:16AM -0300, Alexandre Oliva wrote:
Talking of dm-mirror, I haven't kept track of it; does anyone
know how
it guarantees atomic writes to the replicas of an extent? Does it
resync the whole device in case there's say loss of power or a crash
when the devices are out of sync
The way pvmove uses it, yes, it resyncs those parts of the data that were
being moved.
Alasdair
--
agk(a)redhat.com
2:58 p.m.
On Aug 18, 2004, Alasdair G Kergon <agk(a)redhat.com> wrote:
On Wed, Aug 18, 2004 at 05:54:16AM -0300, Alexandre Oliva wrote:
> Talking of dm-mirror, I haven't kept track of it; does anyone know how
> it guarantees atomic writes to the replicas of an extent? Does it
> resync the whole device in case there's say loss of power or a crash
> when the devices are out of sync
The way pvmove uses it, yes, it resyncs those parts of the data that
were
being moved.
How about for general use, e.g., as a replacement for RAID 1?
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
11:03 p.m.
On Thu, 12 Aug 2004, Russell Coker wrote:
I just tried rebooted that machine. The LVM setup seems mangled and
it
doesn't boot successfully.
Ah yum. You need to make a copy of the most recent /etc/lvm/archive/
lvm config (the lvm tools should archive automatically) and delete
the snapshop. (just do a diff between that file and the previous
archived lvm config to see which lines to delete), then vgcfgrestore
the edited sans-snapshot file.
Though, if your rootfs is on LVM you possibly will have difficulty
completing above[1].
I think recentish Arjan kernels have dm-mirror support included,
which removes this problem. However, it seems quite flakey. Eg,
taking multiple snapshots of same filesystem seems to kill things..
1. A good reason to not put root on LVM - your rootfs is your primary
rescue partition.. Why would you need LVM for root fs anyway?
regards,
--
Paul Jakma paul(a)clubi.ie paul(a)jakma.org Key ID: 64A2FF6A
Fortune:
A kind of Batman of contemporary letters.
-- Philip Larkin on Anthony Burgess
11:42 p.m.
On Tue, 17 Aug 2004 14:03, Paul Jakma <paul(a)dishone.st> wrote:
On Thu, 12 Aug 2004, Russell Coker wrote:
> I just tried rebooted that machine. The LVM setup seems mangled and it
> doesn't boot successfully.
Ah yum. You need to make a copy of the most recent /etc/lvm/archive/
lvm config (the lvm tools should archive automatically) and delete
the snapshop. (just do a diff between that file and the previous
archived lvm config to see which lines to delete), then vgcfgrestore
the edited sans-snapshot file.
Though, if your rootfs is on LVM you possibly will have difficulty
completing above[1].
Thanks for the suggestion. However I had already fixed the problem by booting
from an install CD and running lvm to remove the unwanted snapshot.
1. A good reason to not put root on LVM - your rootfs is your
primary
rescue partition.. Why would you need LVM for root fs anyway?
When I have multiple versions of Fedora on one machine it makes it much easier
to use LVM for root. The 16 partitions issue might become a problem
otherwise, as well as the label "/" being used. If I can't change sizes of
partitions or spread them around I will get fragmentation on my disk and have
odd spare gigabytes of disk space.
Finally, I work for Red Hat, it's my job to test out new stuff. LVM isn't
really my area, but I've already found a couple of SE Linux issues related to
LVM that other people might have missed.
I probably wouldn't recommend other people use LVM root at this stage.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
8:33 a.m.
Once upon a time, Paul Jakma <paul(a)dishone.st> said:
1. A good reason to not put root on LVM - your rootfs is your primary
rescue partition.. Why would you need LVM for root fs anyway?
Why would you need LVM for any FS?
- Ability to easily resize partitions to meet changing needs. This
applies to root as well (ever had to blow everything away because root
needed to be larger for an upgrade?).
- Ability to easily migrate to new storage. I haven't used this with
Linux LVM, but I have migrated Tru64 AdvFS filesystems from one set of
drives to another without having to shut down; combined with on-line
filesystem resizing, you never need to shut down for storage
maintenance again.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:17 a.m.
On Tue, Aug 17, 2004 at 08:33:17AM -0500, Chris Adams wrote:
Once upon a time, Paul Jakma <paul(a)dishone.st> said:
> 1. A good reason to not put root on LVM - your rootfs is your primary
> rescue partition.. Why would you need LVM for root fs anyway?
One can readily put a rescue image in /boot and add an appropriate Grub
entry. Doing so enables maintenance tasks that require unmounting the
filesystem, e.g., shrinking it, or rolling back to a snapshot, which
are ordinarily difficult with system volumes.
Why would you need LVM for any FS?
- Ability to easily resize partitions to meet changing needs. This
applies to root as well (ever had to blow everything away because root
needed to be larger for an upgrade?).
- Ability to easily migrate to new storage. I haven't used this with
Linux LVM, but I have migrated Tru64 AdvFS filesystems from one set of
drives to another without having to shut down; combined with on-line
filesystem resizing, you never need to shut down for storage
maintenance again.
And, of course,
- Snapshot the filesystem for consistent backups, and background fsck.
Regards,
Bill Rugolsky
7227
days inactive
7234
days old
13 comments
7 participants
participants (7)
-
Alasdair G. Kergon -
Alexandre Oliva -
Bill Rugolsky Jr. -
Chris Adams -
Paul Jakma -
Razvan Corneliu C.R. "d3vi1" VILT -
Russell Coker