[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [linux-lvm] kernel panic on lvcreate



There is a working patch for this issue in kernel-2.6.18-178.el5. If anyone needs it sooner, they do have a test kernel available for download. 

Christopher Hawkins

----- "Christopher Hawkins" <chawkins bplinux com> wrote:

> It is reported here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=539328
> 
> That is definitely the one. And it sounds like they have a potential
> fix... I have already emailed the developers there asking if I can
> help test their patch, so hopefully soon I can post back and report
> status. 
> 
> Christopher Hawkins
> 
> ----- "Stuart D. Gathman" <stuart bmsi com> wrote:
> 
> > On Wed, 9 Dec 2009, Christopher Hawkins wrote:
> > 
> > > After some time I revisited this issue on a freshly installed
> Centos
> > 5.4 box,
> > > latest kernel (2.6.18-164.6.1.el5 ) and the panic is still
> > reproducible. Any
> > > time I create a snapshot of the root filesystem, kernel panics.
> The
> > LVM HOWTO
> > > says to post bug reports to this list. Is this the proper place?
> > 
> > Bummer.  I would post the bug on Centos bugzilla also.  Please post
> > the
> > bug number here if you do it (cause I'll get to it eventually).
> > 
> > Thanks for testing this.  I have the same problem, and have a new
> > client
> > to install by next year - so not much time to work on it.
> > 
> > Now that we know it is not yet fixed, we can form theories as to
> what
> > is going wrong.  My guess is that the problem is caused by the fact
> > that
> > lvm is updating files in /etc/lvm on the root filesystem while
> taking
> > the snapshot.  These updates are done by user space programs, so I
> > would
> > further speculate that *any* snapshot would crash if an update
> > happened exactly
> > when creating the snapshot - i.e. the atomic nature of snapshot
> > creation has
> > been broken.  The lvm user space probably does fsync() on files
> > in /etc/lvm, which might be involved in triggering the crash.
> > 
> > We could test the first theory by moving /etc/lvm to another volume
> > (I
> > sometimes put it on /boot - a non LVM filesystem - for easier
> > disaster
> > recovery.) Naturally, I wouldn't go moving /etc/lvm on a production
> > server.
> > 
> > Testing the second hypothesis is less certain, and would basically
> > involve
> > trying snapshots of LVs undergoing heavy updating.
> > 
> > -- 
> > 	      Stuart D. Gathman <stuart bmsi com>
> >     Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703
> > 591-6154
> > "Confutatis maledictis, flammis acribus addictis" - background song
> > for
> > a Microsoft sponsored "Where do you want to go from here?"
> > commercial.
> > 
> > _______________________________________________
> > 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/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]