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

[linux-lvm] Re: Problems running with LVM on RedHat 7.2



In RedHat 7.2, the /etc/rc.d/rc.sysinit file was modified from previous
RedHat distributions.   In the RedHat 7.2 /etc/rc.d/rc.sysinit,  after
checking
for /proc/lvm and /etc/lvmtab, "rc.sysinit" now calls BOTH "vgscan" and
"vgchange".   In previous distributions of RedHat, ONLY "vgchange" was
executed to activate volume groups specified in /etc/lvmtab.

The problem with running "vgscan" with every boot, is "vgscan" first
destroys /etc/lvmtab and all the files in /etc/lvmtab.d.   These are very
important files containing your LVM Volume Group description.  These files
were probably "good" files when your system was shutdown.   If "vgscan"
runs into any problem while running, it will fail to recreate these files,
and you will not be able to access your volume groups without first
restoring these files.

In my view "vgscan" should only be run manually, and should not be run
automatically on every boot.  Running "vgscan" on every boot is not
necessary,
and can potentially cause serious problems.

Jim West
----- Forwarded by James T West/Austin/IBM on 03/01/2002 09:04 AM -----
                                                                                                                                        
                      linux-lvm-request@                                                                                                
                      sistina.com               To:       linux-lvm sistina com                                                         
                      Sent by:                  cc:                                                                                     
                      linux-lvm-admin si        Subject:  linux-lvm digest, Vol 1 #536 - 10 msgs                                        
                      stina.com                                                                                                         
                                                                                                                                        
                                                                                                                                        
                      03/01/2002 04:00                                                                                                  
                      AM                                                                                                                
                      Please respond to                                                                                                 
                      linux-lvm                                                                                                         
                                                                                                                                        
                                                                                                                                        



Send linux-lvm mailing list submissions to
             linux-lvm sistina com

To subscribe or unsubscribe via the World Wide Web, visit
             http://lists.sistina.com/mailman/listinfo/linux-lvm
or, via email, send a message with subject or body 'help' to
             linux-lvm-request sistina com

You can reach the person managing the list at
             linux-lvm-admin sistina com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of linux-lvm digest..."


Today's Topics:

   1. Trouble running LVM under Redhat 7.2? (Aslak Sommerfelt Skretting)
   2. LVM1.0.3 tools on a kernel with LVM1.0.1-rc4? (Turbo Fredriksson)
   3. Re: Cluster LVM (Joe Thornber)
   4. Re: Cluster LVM (Prashant Kharche)
   5. Re: Cluster LVM (Joe Thornber)
   6. Re: Cluster LVM (Prashant Kharche)
   7. Re: Cluster LVM (Remco Post)
   8. Re: Cluster LVM (Joe Thornber)
   9. Re: LVM1.0.3 tools on a kernel with LVM1.0.1-rc4? (Heinz J .
Mauelshagen)
  10. Re: filesystem corruption... (Heinz J . Mauelshagen)

--__--__--

Message: 1
From: "Aslak Sommerfelt Skretting" <aslak skretting org>
To: <linux-lvm sistina com>
Date: Thu, 28 Feb 2002 12:21:49 -0800
Subject: [linux-lvm] Trouble running LVM under Redhat 7.2?
Reply-To: linux-lvm sistina com

Hello everyone.

Does anyone know of any problems that might occur when running LVM under
Redhat 7.2?

This is my lvm setup, on two 120gb disks and two 100gb disks.

root space uNF no:/space# vgdisplay -v storage
--- Volume group ---
VG Name               storage
VG Access             read/write
VG Status             available/resizable
VG #                  0
MAX LV                255
Cur LV                1
Open LV               1
MAX LV Size           2 TB
Max PV                255
Cur PV                4
Act PV                4
VG Size               406.41 GB
PE Size               32 MB
Total PE              13005
Alloc PE / Size       13005 / 406.41 GB
Free  PE / Size       0 / 0
VG UUID               0Vf6Xc-j0GQ-y068-OF8a-mF1e-9jDT-yKL6ny

--- Logical volume ---
LV Name                /dev/storage/space
VG Name                storage
LV Write Access        read/write
LV Status              available
LV #                   1
# open                 1
LV Size                406.41 GB
Current LE             13005
Allocated LE           13005
Allocation             next free
Read ahead sectors     120
Block device           58:0


--- Physical volumes ---
PV Name (#)           /dev/hde1 (4)
PV Status             available / allocatable
Total PE / Free PE    2980 / 0

PV Name (#)           /dev/hdc1 (2)
PV Status             available / allocatable
Total PE / Free PE    3576 / 0

PV Name (#)           /dev/hdd1 (3)
PV Status             available / allocatable
Total PE / Free PE    2980 / 0

PV Name (#)           /dev/hdb3 (1)
PV Status             available / allocatable
Total PE / Free PE    3469 / 0


I am able to both install, and setup lvm without any trouble at all, but it
seems the system gets really unstable. I have tried using both the Redhat
2.4.7-10 kernel (the one redhat 7.2 ships with, and the 2.4.17 kernel. I
have also tried using both lvm 1.0.2 and 1.0.3.

When reinstalling, i first export the lvm setup, do the system reinstall,
install lvm, compile new kernel, then when it is up and running, i import
the lvm setup from the other disks. All this seems to be running fine.

But when running normally, the system seems to get itself into a lot of
'Kernel Oops' problems. I have never seen these before, but now i get them
all the time. They either cause pretty much every application i try to run
after the Oops to segfault, or they simply freeze the system. When it gets
back up, and the system needs to be fsck'ed i also experience a lot of
problems getting fsck to run properly. when running fsck /dev/hda1 (which
is
a normal ext2 partition, not lvm) i will get the same Kernel oops, and fsck
will fail. I will eventually get the system back up and running normally,
but it takes time. Other commands that i have seen give the same kernel
oops
are umount, fsck, proftpd and smbd... I found two examples of this Kernel
Oops code in /var/log/messages, and have included them below, if anyone is
able to gather any information from them.


Any input as to why the system is so unstable would be highly appreciated.
Does the system dislike that i set the PE size to 32? Are there any
problems
caused by running lvm under Redhat 7.2? (If so, I could go back to 7.1)


Kind Regards
Aslak Sommerfelt Skretting


Included:

/var/log/messages:


Feb 26 02:34:32 space sshd(pam_unix)[1217]: session closed for user tek
Feb 26 04:02:03 space syslogd 1.4.1: restart.
Feb 26 19:03:36 space sshd(pam_unix)[2639]: session opened for user tek by
(uid=0)
Feb 26 19:03:39 space su(pam_unix)[2680]: session opened for user root by
tek(uid=500)
Feb 26 19:11:49 space proftpd[2751]: space.uNF.no - ProFTPD terminating
(signal 11)
Feb 26 19:11:49 space proftpd[2751]: space.uNF.no - ProFTPD 1.2.4
standalone
mode SHUTDOWN
Feb 26 20:14:49 space su(pam_unix)[2680]: session closed for user root
Feb 26 20:14:50 space sshd(pam_unix)[2639]: session closed for user tek
Feb 26 23:24:21 space kernel: Unable to handle kernel paging request at
virtual address 802aeca8
Feb 26 23:24:21 space kernel:  printing eip:
Feb 26 23:24:21 space kernel: c013e457
Feb 26 23:24:21 space kernel: *pde = 00000000
Feb 26 23:24:21 space kernel: Oops: 0000
Feb 26 23:24:21 space kernel: CPU:    0
Feb 26 23:24:21 space kernel: EIP:    0010:[link_path_walk+1703/2048]
Not
tainted
Feb 26 23:24:21 space kernel: EIP:    0010:[<c013e457>]    Not tainted
Feb 26 23:24:21 space kernel: EFLAGS: 00010282
Feb 26 23:24:21 space kernel: eax: 802aec80   ebx: ddebbf64   ecx: 00000000
edx: c262c1b8
Feb 26 23:24:21 space kernel: esi: c8880dc0   edi: ddebbf9c   ebp: c8877820
esp: ddebbf38
Feb 26 23:24:21 space kernel: ds: 0018   es: 0018   ss: 0018
Feb 26 23:24:21 space kernel: Process smbd (pid: 2844, stackpage=ddebb000)
Feb 26 23:24:21 space kernel: Stack: 00000009 c2a7802d c8880dc0 00000000
00000000 c8880e40 00001000 fffffff4
Feb 26 23:24:21 space kernel:        c2a78000 08199680 c013d89e c2a7800f
0000001e 6ea99c29 ddeba000 00000000
Feb 26 23:24:21 space kernel:        c2a78000 ddebbf9c 00000009 c013ea23
ddeba000 081f9bc8 bfffea80 bfffe208
Feb 26 23:24:21 space kernel: Call Trace: [getname+94/160]
[__user_walk+51/80] [sys_stat64+20/112]
[error_code+52/60][system_call+51/56]
Feb 26 23:24:21 space kernel: Call Trace: [<c013d89e>] [<c013ea23>]
[<c013b504>] [<c010721c>] [<c010712b>]
Feb 26 23:24:21 space kernel:
Feb 26 23:24:21 space kernel: Code: 8b 50 28 85 d2 0f 84 8e 00 00 00 bb 00
e0 ff ff 21 e3 8b 93
Feb 26 23:24:35 space kernel:  <1>Unable to handle kernel paging request at
virtual address 802aeca8
Feb 26 23:24:35 space kernel:  printing eip:
Feb 26 23:24:35 space kernel: c013e457
Feb 26 23:24:35 space kernel: *pde = 00000000
Feb 26 23:24:35 space kernel: Oops: 0000
Feb 26 23:24:35 space kernel: CPU:    0
Feb 26 23:24:35 space kernel: EIP:    0010:[link_path_walk+1703/2048]
Not
tainted
Feb 26 23:24:35 space kernel: EIP:    0010:[<c013e457>]    Not tainted
Feb 26 23:24:35 space kernel: EFLAGS: 00010282
Feb 26 23:24:35 space kernel: eax: 802aec80   ebx: ddebbf64   ecx: 00000000
edx: 00000000
Feb 26 23:24:35 space kernel: esi: c8880dc0   edi: ddebbf9c   ebp: c8877820
esp: ddebbf38
Feb 26 23:24:35 space kernel: ds: 0018   es: 0018   ss: 0018
Feb 26 23:24:35 space kernel: Process smbd (pid: 2856, stackpage=ddebb000)
Feb 26 23:24:35 space kernel: Stack: 00000009 dafc302d c8880dc0 08208000
00000077 00000077 00001000 fffffff4
Feb 26 23:24:35 space kernel:        dafc3000 08199680 c013d89e dafc300f
0000001e 6ea99c29 ddeba000 00000000
Feb 26 23:24:35 space kernel:        dafc3000 ddebbf9c 00000009 c013ea23
ddeba000 081f9bd0 bfffea80 bfffe208
Feb 26 23:24:35 space kernel: Call Trace: [getname+94/160]
[__user_walk+51/80] [sys_stat64+20/112] [error_code+52/60]
[system_call+51/56]
Feb 26 23:24:35 space kernel: Call Trace: [<c013d89e>] [<c013ea23>]
[<c013b504>] [<c010721c>] [<c010712b>]
Feb 26 23:24:35 space kernel:
Feb 26 23:24:35 space kernel: Code: 8b 50 28 85 d2 0f 84 8e 00 00 00 bb 00
e0 ff ff 21 e3 8b 93
Feb 26 23:25:42 space atd: atd shutdown succeeded
Feb 26 23:25:42 space Font Server[938]: terminating
Feb 26 23:25:43 space xfs: xfs shutdown succeeded
Feb 26 23:25:43 space rpc.mountd: Caught signal 15, un-registering and
exiting.
Feb 26 23:25:43 space nfs: rpc.mountd shutdown succeeded
Feb 26 23:25:47 space kernel:  <4>nfsd: last server has exited
Feb 26 23:25:47 space kernel: nfsd: unexporting all filesystems
Feb 26 23:25:47 space nfs: nfsd shutdown succeeded
Feb 26 23:25:47 space nfs: Shutting down NFS services:  succeeded
Feb 26 23:25:47 space nfs: rpc.rquotad shutdown succeeded
Feb 26 23:25:47 space sshd: sshd -TERM succeeded
Feb 26 23:25:47 space sendmail: sendmail shutdown succeeded
Feb 26 23:25:48 space smb: smbd shutdown succeeded
Feb 26 23:25:48 space smb: nmbd shutdown succeeded
Feb 26 23:25:48 space xinetd[829]: Exiting...
Feb 26 23:25:48 space xinetd: xinetd shutdown succeeded
Feb 26 23:25:48 space crond: crond shutdown succeeded
Feb 26 23:25:48 space dd: 1+0 records in
Feb 26 23:25:48 space dd: 1+0 records out
Feb 26 23:25:48 space random: Saving random seed:  succeeded
Feb 26 23:25:48 space rpc.statd[580]: Caught signal 15, un-registering and
exiting.
Feb 26 23:25:48 space nfslock: rpc.statd shutdown succeeded
Feb 26 23:25:49 space portmap: portmap shutdown succeeded
Feb 26 23:25:49 space kernel: Kernel logging (proc) stopped.
Feb 26 23:25:49 space kernel: Kernel log daemon terminating.
Feb 26 23:25:50 space syslog: klogd shutdown succeeded
Feb 26 23:25:50 space exiting on signal 15









--__--__--

Message: 2
To: linux-lvm sistina com
From: Turbo Fredriksson <turbo bayour com>
Organization: Bah!
Date: 28 Feb 2002 12:22:51 +0100
Subject: [linux-lvm] LVM1.0.3 tools on a kernel with LVM1.0.1-rc4?
Reply-To: linux-lvm sistina com

Is this possible?

cracking $400 million in gold bullion Noriega president supercomputer
Cocaine PLO fissionable ammonium ammunition spy class struggle Rule
Psix South Africa Panama
[See http://www.aclu.org/echelonwatch/index.html for more about this]


--__--__--

Message: 3
Date: Thu, 28 Feb 2002 11:30:40 +0000
To: linux-lvm sistina com
Subject: Re: [linux-lvm] Cluster LVM
From: Joe Thornber <joe fib011235813 fsnet co uk>
Reply-To: linux-lvm sistina com

On Thu, Feb 28, 2002 at 02:59:51AM -0800, Prashant Kharche wrote:
> When tools are run they run with a lock
> and and at that time the filesystem cannot access the
> volume groups.

How are you preventing remote nodes from accessing the volume groups ?
Or are you working on an 'offline' solution, where there can be no
users of logical volumes while you resize them ?

- Joe


--__--__--

Message: 4
Date: Thu, 28 Feb 2002 05:03:37 -0800 (PST)
From: Prashant Kharche <pdkharche yahoo com>
Subject: Re: [linux-lvm] Cluster LVM
To: linux-lvm sistina com
Reply-To: linux-lvm sistina com


  Basically, we are putting a lock on the VG while it
is getting resized or for any tool which tries to
access VG .. So that no other user can access the
metadata of that VG..
WE ARE ONLY MATAINING THE CONSISTENCY OF THE VG
METADATA..
We thought of protecting VG DATA (NOT METADATA), but
it becomes very completed.. so as if now we are not
taking care of FS access..
--- Joe Thornber <joe fib011235813 fsnet co uk> wrote:
> On Thu, Feb 28, 2002 at 02:59:51AM -0800, Prashant
> Kharche wrote:
> > When tools are run they run with a lock
> > and and at that time the filesystem cannot access
> the
> > volume groups.
>
> How are you preventing remote nodes from accessing
> the volume groups ?
> Or are you working on an 'offline' solution, where
> there can be no
> users of logical volumes while you resize them ?
>
> - Joe
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm sistina com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com


--__--__--

Message: 5
Date: Thu, 28 Feb 2002 14:32:17 +0000
To: linux-lvm sistina com
Subject: Re: [linux-lvm] Cluster LVM
From: Joe Thornber <joe fib011235813 fsnet co uk>
Reply-To: linux-lvm sistina com

On Thu, Feb 28, 2002 at 05:03:37AM -0800, Prashant Kharche wrote:
>
>   Basically, we are putting a lock on the VG while it
> is getting resized or for any tool which tries to
> access VG .. So that no other user can access the
> metadata of that VG..
> WE ARE ONLY MATAINING THE CONSISTENCY OF THE VG
> METADATA..
> We thought of protecting VG DATA (NOT METADATA), but
> it becomes very completed.. so as if now we are not
> taking care of FS access..

You need to take care that the volume groups running on all nodes
*always* reflect the metadata on disk.

For instance, if have two nodes running vg0/lvol0, and I issue a
pvmove from node1, when does node2 find out that the mapping has
changed ?

- Joe


--__--__--

Message: 6
Date: Thu, 28 Feb 2002 07:06:58 -0800 (PST)
From: Prashant Kharche <pdkharche yahoo com>
Subject: Re: [linux-lvm] Cluster LVM
To: linux-lvm sistina com
Reply-To: linux-lvm sistina com


--- Joe Thornber <joe fib011235813 fsnet co uk> wrote:
> On Thu, Feb 28, 2002 at 05:03:37AM -0800, Prashant
> Kharche wrote:
> >
> >   Basically, we are putting a lock on the VG while
> it
> > is getting resized or for any tool which tries to
> > access VG .. So that no other user can access the
> > metadata of that VG..
> > WE ARE ONLY MATAINING THE CONSISTENCY OF THE VG
> > METADATA..
> > We thought of protecting VG DATA (NOT METADATA),
> but
> > it becomes very completed.. so as if now we are
> not
> > taking care of FS access..
>
> You need to take care that the volume groups running
> on all nodes
> *always* reflect the metadata on disk.
>
> For instance, if have two nodes running vg0/lvol0,
> and I issue a
> pvmove from node1, when does node2 find out that the
> mapping has
> changed ?
>
> - Joe
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm sistina com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at
http://www.sistina.com/lvm/Pages/howto.html

when node1 issues a command pvmove, LOCK MANAGER will
block all the nodes from accessing the METADATA for
that VG and as soon as it finishes updating the
METADATA, pvmove itself writes the updated kernel VGDA
on the DISK.. so for this period, METADATA consistency
is maintained.

__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com


--__--__--

Message: 7
From: Remco Post <r post sara nl>
To: linux-lvm sistina com
Subject: Re: [linux-lvm] Cluster LVM
Date: Thu, 28 Feb 2002 16:43:25 +0100
Reply-To: linux-lvm sistina com

>
> --- Joe Thornber <joe fib011235813 fsnet co uk> wrote:
> > On Thu, Feb 28, 2002 at 05:03:37AM -0800, Prashant
> > Kharche wrote:
> > >
> > >   Basically, we are putting a lock on the VG while
> > it
> > > is getting resized or for any tool which tries to
> > > access VG .. So that no other user can access the
> > > metadata of that VG..
> > > WE ARE ONLY MATAINING THE CONSISTENCY OF THE VG
> > > METADATA..
> > > We thought of protecting VG DATA (NOT METADATA),
> > but
> > > it becomes very completed.. so as if now we are
> > not
> > > taking care of FS access..
> >
> > You need to take care that the volume groups running
> > on all nodes
> > *always* reflect the metadata on disk.
> >
> > For instance, if have two nodes running vg0/lvol0,
> > and I issue a
> > pvmove from node1, when does node2 find out that the
> > mapping has
> > changed ?
> >
> > - Joe
> >
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm sistina com
> > http://lists.sistina.com/mailman/listinfo/linux-lvm
> > read the LVM HOW-TO at
> http://www.sistina.com/lvm/Pages/howto.html
>
> when node1 issues a command pvmove, LOCK MANAGER will
> block all the nodes from accessing the METADATA for
> that VG and as soon as it finishes updating the
> METADATA, pvmove itself writes the updated kernel VGDA
> on the DISK.. so for this period, METADATA consistency
> is maintained.
>

During the pv move, not only needs the metadata be protected, but also the
fs
data,eg. when one server is moving a data block from one disk tot the
other,
all other servers must be notified that that block is currently
inaccessable,
so no fs data will get lost during transaction, or am I missing something
here?


--
Met vriendelijke groeten,

Remco Post

SARA - Stichting Academisch Rekencentrum Amsterdam
High Performance Computing  Tel. +31 20 592 8008    Fax. +31 20 668 3167

"I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course - the computer
industry
didn't even foresee that the century was going to end." -- Douglas Adams




--__--__--

Message: 8
Date: Thu, 28 Feb 2002 18:00:21 +0000
To: linux-lvm sistina com
Subject: Re: [linux-lvm] Cluster LVM
From: Joe Thornber <joe fib011235813 fsnet co uk>
Reply-To: linux-lvm sistina com

On Thu, Feb 28, 2002 at 07:06:58AM -0800, Prashant Kharche wrote:
> when node1 issues a command pvmove, LOCK MANAGER will
> block all the nodes from accessing the METADATA for
> that VG and as soon as it finishes updating the
> METADATA, pvmove itself writes the updated kernel VGDA
> on the DISK.. so for this period, METADATA consistency
> is maintained.

This is not enough, you will end up with a trashed system since node2
will still be writing data to the wrong place.  I think you should
consider only doing offline operations.  ie, acquiring the lock should
fail if any other nodes have activated the vg.

If you really insist on doing live operations I suggest you look at
the device-mapper driver (LVM2), which contains the suspend
functionality that you will need.

- Joe


--__--__--

Message: 9
Date: Fri, 1 Mar 2002 10:49:24 +0100
From: "Heinz J . Mauelshagen" <mauelshagen sistina com>
To: linux-lvm sistina com
Subject: Re: [linux-lvm] LVM1.0.3 tools on a kernel with LVM1.0.1-rc4?
Reply-To: linux-lvm sistina com

On Thu, Feb 28, 2002 at 12:22:51PM +0100, Turbo Fredriksson wrote:
> Is this possible?

Yes.

>
> cracking $400 million in gold bullion Noriega president supercomputer
> Cocaine PLO fissionable ammonium ammunition spy class struggle Rule
> Psix South Africa Panama

Was that English?

> [See http://www.aclu.org/echelonwatch/index.html for more about this]
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm sistina com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

--

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen Sistina com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



--__--__--

Message: 10
Date: Fri, 1 Mar 2002 10:58:59 +0100
From: "Heinz J . Mauelshagen" <mauelshagen sistina com>
To: linux-lvm sistina com
Subject: Re: [linux-lvm] filesystem corruption...
Reply-To: linux-lvm sistina com

On Thu, Feb 28, 2002 at 10:07:03AM +0100, Anders Widman wrote:
>
> > On Thu, Feb 28, 2002 at 09:35:53AM +0100, Anders Widman wrote:
> >>
> >> >> On Wednesday, February 27, 2002 04:42:28 PM -0700 Andreas Dilger
<adilger clusterfs com> wrote:
> >>
> >> >>> On Feb 27, 2002  23:36 +0100, Anders Widman wrote:
> >> >>>> Unfortunatley, something went seriously wrong. I can't mount the
disk
> >> >>>> any more, or use reiserfsck. They (mount/reiserfsck) say there
isn't
> >> >>>> a valid filesystem on the device. Vgscan does however find all
devices
> >> >>>> and can activate the volume group, but reiserfsck doesn't work.
> >> >>>>
> >> >>>> What should I do to be able to save a s much data as possible?
> >> >>>
> >> >>> dd if=/dev/vg/lv of=/new/disk conv=sync,noerror
> >>
> >> >> Then we should be able to use debugreiserfs and reiserfsck to
> >> >> find a copy of the super in the log, or just recreate it.
> >>
> >> >> -chris
> >>
> >> > So. How much space would this require on the 'new' disk? The same
> >> > amount as the entire LV? If that is, it would be impossible (for me,
> >> > economically) to do this.
> >>
> >> > The disk with bad blocks is 80GB, and I have a "spare" 80GB disk,
but
> >> > not more.
> >>
> >> > //Anders
> >>
> >> Oh, I forgot to ask how I can recover the filsystem
> >> header/suprtblock.. What exactly is "dd if=/dev/vg/lv of=/new/disk
> >> conv=sync,noerror" doing to the data, except copying it to the new
> >> device?
>
> > It copies all it can read to another sane device so that youe don't
loose
> > more data if your drive turns worse.
>
> > After that, you want to use "reiserfsck --rebuild-sb /dev/vg/lv".
>
> Ok. Unfortunatley, I can't get enough storage to copy all data. Would
> it be possible to just copy the data from the broken disk to a new,

So /dev/vg/lv is bigger than that disk?

> identical disk (I have a "spare" disk of the same model), and then
> rebuild the filsystem?

Well, then pvcreate the spare disk, add it to your VG and
"pvmove -i /dev/BrokenDisk /dev/SaneDisk" data over.

You need to have recent LVM 1.0.3 tools in order to use the -i option of
pvmove, which ignores read errors and you need to patch liblvm.h with the
following one to make pvmove work correctly.

After that repair the filesystem in /dev/vg/lv.

diff -u -B -r1.43 -r1.44
--- LVM/tools/lib/liblvm.h      18 Feb 2002 16:37:18 -0000      1.43
+++ LVM/tools/lib/liblvm.h      20 Feb 2002 10:49:14 -0000      1.44
@@ -93,10 +93,10 @@
 #include <time.h>
 #include <limits.h>
 #ifdef _G_LSEEK64
-int lseek64 ( unsigned int, unsigned long long, unsigned int);
+loff_t lseek64 ( int, loff_t, int);
 #define llseek lseek64
 #else
-int llseek ( unsigned int, unsigned long long, unsigned int);
+loff_t llseek ( int, loff_t, int);
 #endif

 #include <sys/ioctl.h>
@@ -130,7 +130,7 @@
 #define        LVMTAB                  "/etc/lvmtab"   /* LVM table of VGs
*/
 #define        LVMTAB_DIR              "/etc/lvmtab.d" /* storage dir VG
data */
 #define        LVMTAB_MINSIZE   ( sizeof ( vg_t) + sizeof ( lv_t) + sizeof
( pv_t))
-#define        LVM_DEV                 "/dev/lvm"
+#define        LVM_DEV                 LVM_DIR_PREFIX "lvm"
 #define        VG_BACKUP_DIR           "/etc/lvmconf"
 #define        DISK_NAME_LEN           8
 #define        LV_MIN_NAME_LEN         5


>
> Thanks for your time!
>
> Regards,
> Anders
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm sistina com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

--

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen Sistina com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-




--__--__--

_______________________________________________
linux-lvm mailing list
linux-lvm sistina com
http://lists.sistina.com/mailman/listinfo/linux-lvm


End of linux-lvm Digest






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