* [linux-lvm] Help! unable to mount lv's - can't see why!
@ 2002-09-18 6:37 Robin Edgar - Tripany
2002-09-18 8:20 ` Heinz J . Mauelshagen
2002-09-18 8:27 ` Robin Edgar - Tripany
0 siblings, 2 replies; 14+ messages in thread
From: Robin Edgar - Tripany @ 2002-09-18 6:37 UTC (permalink / raw)
To: linux-lvm
[-- Attachment #1: Type: text/plain, Size: 9502 bytes --]
Hi,
I had 4 (ide) disks in an array (and 1 vg) of which one (hde) broke. As I was not too sure of the stability of the system, I decided to do a dd of the disk byte by byte to another identical disk. After this was done (with loads of sector unreadable errors) I replaced the old disk with the new disk, rebooted the system and by all standards all seems well (see below):
Unfortunately, only the /dev/tripserv_vol/docu will mount well!
/dev/tripserv_vol/pages gives the following error:
# mount /dev/tripserv_vol/pages /c
mount: you must specify the filesystem type
# mount /dev/tripserv_vol/pages /c -t ext3
mount: wrong fs type, bad option, bad superblock on /dev/tripserv_vol/pages,
or too many mounted file systems
Anyone have any ideas why it won't mount?!
Cheers,
Robin Edgar
#pvscan:
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE PV "/dev/hdg1" of VG "tripserv_vol" [38.16 GB / 7.93 GB free]
pvscan -- ACTIVE PV "/dev/hdh1" of VG "tripserv_vol" [38.16 GB / 8.01 GB free]
pvscan -- ACTIVE PV "/dev/hde1" of VG "tripserv_vol" [55.91 GB / 0 free]
pvscan -- ACTIVE PV "/dev/hdf1" of VG "tripserv_vol" [55.91 GB / 3.37 GB free]
pvscan -- total: 4 [188.16 GB] / in use: 4 [188.16 GB] / in no VG: 0 [0]
(identical output to before changing the disks around)
#pvdisplay /dev/hde1
--- Physical volume ---
PV Name /dev/hde1
VG Name tripserv_vol
PV Size 55.92 GB [117266625 secs] / NOT usable 4.18 MB [LVM: 179 KB]
PV# 1
PV Status available
Allocatable yes (but full)
Cur LV 20
PE Size (KByte) 4096
Total PE 14313
Free PE 0
Allocated PE 14313
PV UUID KCIKwa-3lvx-k7bj-27ks-hGlI-oZRo-5q7CjM
(also identical)
#vgck -v
vgck -- locking logical volume manager
vgck -- finding all volume group(s)
vgck -- checking volume group name "tripserv_vol"
vgck -- checking existence of volume group "tripserv_vol"
vgck -- reading volume group data for "tripserv_vol" from lvmtab
vgck -- checking volume group consistency of "tripserv_vol" in lvmtab
vgck -- VGDA of "tripserv_vol" in lvmtab is consistent
vgck -- reading volume group data for "tripserv_vol" from physical volume(s)
vgck -- checking volume group consistency of "tripserv_vol" on physical volumes
vgck -- VGDA of "tripserv_vol" on physical volumes is consistent
vgck -- unlocking logical volume manager
# vgdisplay
--- Volume group ---
VG Name tripserv_vol
VG Access read/write
VG Status available/resizable
VG # 0
MAX LV 255
Cur LV 22
Open LV 1
MAX LV Size 255.99 GB
Max PV 255
Cur PV 4
Act PV 4
VG Size 188.13 GB
PE Size 4 MB
Total PE 48162
Alloc PE / Size 43220 / 168.83 GB
Free PE / Size 4942 / 19.30 GB
VG UUID KDiCWx-ae2w-oDnx-Hl5O-Amhd-fIM3-y51bIX
# vgscan -v
vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
vgscan -- creating empty "/etc/lvmtab" and "/etc/lvmtab.d"
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- scanning for all active volume group(s) first
vgscan -- found active volume group "tripserv_vol"
vgscan -- reading data of volume group "tripserv_vol" from physical volume(s)
vgscan -- inserting "tripserv_vol" into lvmtab
vgscan -- backing up volume group "tripserv_vol"
vgscan -- checking volume group name "tripserv_vol"
vgscan -- checking volume group consistency of "tripserv_vol"
vgscan -- checking existence of "/etc/lvmtab.d"
vgscan -- storing volume group data of "tripserv_vol" in "/etc/lvmtab.d/tripserv_vol.tmp"
vgscan -- storing physical volume data of "tripserv_vol" in "/etc/lvmtab.d/tripserv_vol.tmp"
vgscan -- storing logical volume data of volume group "tripserv_vol" in "/etc/lvmtab.d/tripserv_vol.tmp"
vgscan -- renaming "/etc/lvmtab.d/tripserv_vol.tmp" to "/etc/lvmtab.d/tripserv_vol"
vgscan -- removing special files and directory for volume group "tripserv_vol"
vgscan -- creating directory and group character special file for "tripserv_vol"
vgscan -- creating block device special files for tripserv_vol
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
vgscan -- WARNING: This program does not do a VGDA backup of your volume group
#lvscan
lvscan -- ACTIVE Original "/dev/tripserv_vol/docu" [512 MB] striped[4]
lvscan -- ACTIVE Original "/dev/tripserv_vol/install" [10 GB] striped[4]
lvscan -- ACTIVE Original "/dev/tripserv_vol/pages" [20 GB] striped[4]
lvscan -- ACTIVE "/dev/tripserv_vol/gfx" [10 GB] striped[4]
lvscan -- ACTIVE "/dev/tripserv_vol/sfx" [10 GB] striped[4]
lvscan -- ACTIVE "/dev/tripserv_vol/people" [20 GB] striped[4]
lvscan -- ACTIVE Original "/dev/tripserv_vol/dim" [2 GB] striped[4]
lvscan -- ACTIVE "/dev/tripserv_vol/mp3" [20 GB] striped[4]
lvscan -- ACTIVE "/dev/tripserv_vol/applications" [2 GB] striped[4]
lvscan -- ACTIVE Original "/dev/tripserv_vol/code" [512 MB] striped[4]
lvscan -- ACTIVE "/dev/tripserv_vol/dumpdir" [10 GB] striped[4]
lvscan -- ACTIVE Original "/dev/tripserv_vol/homes" [10 GB] striped[4]
lvscan -- ACTIVE Original "/dev/tripserv_vol/info" [5 GB] striped[4]
lvscan -- ACTIVE "/dev/tripserv_vol/log" [252 MB] striped[3]
lvscan -- ACTIVE "/dev/tripserv_vol/store" [608 MB] striped[4]
lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/docusnap" [492.19 MB] of /dev/tripserv_vol/docu
lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/installsnap" [9.84 GB] of /dev/tripserv_vol/install
lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/dimsnap" [1.97 GB] of /dev/tripserv_vol/dim
lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/codesnap" [504 MB] of /dev/tripserv_vol/code
lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/pagessnap" [19.69 GB] of /dev/tripserv_vol/pages
lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/infosnap" [4.92 GB] of /dev/tripserv_vol/info
lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/homessnap" [9.84 GB] of /dev/tripserv_vol/homes
lvscan -- 22 logical volumes with 168.08 GB total in 1 volume group
lvscan -- 22 active logical volumes
# lvdisplay /dev/tripserv_vol/docu
--- Logical volume ---
LV Name /dev/tripserv_vol/docu
VG Name tripserv_vol
LV Write Access read/write
LV snapshot status source of
/dev/tripserv_vol/docusnap [active]
LV Status available
LV # 1
# open 1
LV Size 512 MB
Current LE 128
Allocated LE 128
Stripes 4
Stripe size (KByte) 4
Allocation next free
Read ahead sectors 120
Block device 58:0
# lvdisplay /dev/tripserv_vol/people
--- Logical volume ---
LV Name /dev/tripserv_vol/people
VG Name tripserv_vol
LV Write Access read/write
LV Status available
LV # 6
# open 0
LV Size 20 GB
Current LE 5120
Allocated LE 5120
Stripes 4
Stripe size (KByte) 4
Allocation next free
Read ahead sectors 120
Block device 58:5
# lvdisplay /dev/tripserv_vol/pages
--- Logical volume ---
LV Name /dev/tripserv_vol/pages
VG Name tripserv_vol
LV Write Access read/write
LV snapshot status source of
/dev/tripserv_vol/pagessnap [active]
LV Status available
LV # 3
# open 0
LV Size 20 GB
Current LE 5120
Allocated LE 5120
Stripes 4
Stripe size (KByte) 4
Allocation next free
Read ahead sectors 120
Block device 58:2
tripserv:/# lvdisplay /dev/tripserv_vol/pagessnap
--- Logical volume ---
LV Name /dev/tripserv_vol/pagessnap
VG Name tripserv_vol
LV Write Access read only
LV snapshot status active destination for /dev/tripserv_vol/pages
LV Status available
LV # 20
# open 0
LV Size 20 GB
Current LE 5120
Allocated LE 5120
snapshot chunk size 64 KB
Allocated to snapshot 0.00% [0/19.69 GB]
Allocated to COW-table 320 MB
Stripes 4
Stripe size (KByte) 4
Allocation next free
Read ahead sectors 120
Block device 58:19
# lvdisplay /dev/tripserv_vol/docusnap
--- Logical volume ---
LV Name /dev/tripserv_vol/docusnap
VG Name tripserv_vol
LV Write Access read only
LV snapshot status active destination for /dev/tripserv_vol/docu
LV Status available
LV # 16
# open 0
LV Size 512 MB
Current LE 128
Allocated LE 128
snapshot chunk size 64 KB
Allocated to snapshot 0.05% [256 KB/492.19 MB]
Allocated to COW-table 7.81 MB
Stripes 4
Stripe size (KByte) 4
Allocation next free
Read ahead sectors 120
Block device 58:15
So it all looks good!
[-- Attachment #2: Type: text/html, Size: 19117 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-lvm] Help! unable to mount lv's - can't see why!
2002-09-18 6:37 [linux-lvm] Help! unable to mount lv's - can't see why! Robin Edgar - Tripany
@ 2002-09-18 8:20 ` Heinz J . Mauelshagen
2002-09-18 9:07 ` Robin Edgar - Tripany
2002-09-18 8:27 ` Robin Edgar - Tripany
1 sibling, 1 reply; 14+ messages in thread
From: Heinz J . Mauelshagen @ 2002-09-18 8:20 UTC (permalink / raw)
To: linux-lvm
On Wed, Sep 18, 2002 at 02:07:18PM +0200, Robin Edgar - Tripany wrote:
> Hi,
>
> I had 4 (ide) disks in an array (and 1 vg) of which one (hde) broke. As I was not too sure of the stability of the system, I decided to do a dd of the disk byte by byte to another identical disk. After this was done (with loads of sector unreadable errors) I replaced the old disk with the new disk, rebooted the system and by all standards all seems well (see below):
Robin,
lots of read errors during dd likely left you with a corrupted primary
superblock of the filesystem.
> Unfortunately, only the /dev/tripserv_vol/docu will mount well!
> /dev/tripserv_vol/pages gives the following error:
>
> # mount /dev/tripserv_vol/pages /c
> mount: you must specify the filesystem type
>
> # mount /dev/tripserv_vol/pages /c -t ext3
> mount: wrong fs type, bad option, bad superblock on /dev/tripserv_vol/pages,
> or too many mounted file systems
>
> Anyone have any ideas why it won't mount?!
You need to figure out, if /dev/tripserv_vol/docu doesn't have *any* extents
allocated on the replaced disk. Try "lvdisplay -v /dev/tripserv_vol/docu"
to achive this. If it has, you'll likely find corrupted files in this one
too.
For the failing mount you might want to try
"mount -r -osb=$ALTERNATE_SUPERBLOCK /dev/tripserv_vol/pages /c".
In case you've got a logical 4k block size of the filesystem,
ALTERNATE_SUPERBLOCK=131072 would access the first backup copy.
See "man mount" and look for the ext2 mount option "sb=" for more information.
In case you have success with using a backup superblock this way, you need to
backup all files you can access successfully first, then recreate the filesystem
and restore. It is unlikely in the case of lots of read errors during dd, that
a fsck will help you. You'll probably end up with piles of lost+found entries.
Regards,
Heinz -- The LVM Guy --
>
> Cheers,
> Robin Edgar
>
> #pvscan:
> pvscan -- reading all physical volumes (this may take a while...)
> pvscan -- ACTIVE PV "/dev/hdg1" of VG "tripserv_vol" [38.16 GB / 7.93 GB free]
> pvscan -- ACTIVE PV "/dev/hdh1" of VG "tripserv_vol" [38.16 GB / 8.01 GB free]
> pvscan -- ACTIVE PV "/dev/hde1" of VG "tripserv_vol" [55.91 GB / 0 free]
> pvscan -- ACTIVE PV "/dev/hdf1" of VG "tripserv_vol" [55.91 GB / 3.37 GB free]
> pvscan -- total: 4 [188.16 GB] / in use: 4 [188.16 GB] / in no VG: 0 [0]
>
> (identical output to before changing the disks around)
>
> #pvdisplay /dev/hde1
> --- Physical volume ---
> PV Name /dev/hde1
> VG Name tripserv_vol
> PV Size 55.92 GB [117266625 secs] / NOT usable 4.18 MB [LVM: 179 KB]
> PV# 1
> PV Status available
> Allocatable yes (but full)
> Cur LV 20
> PE Size (KByte) 4096
> Total PE 14313
> Free PE 0
> Allocated PE 14313
> PV UUID KCIKwa-3lvx-k7bj-27ks-hGlI-oZRo-5q7CjM
>
> (also identical)
>
> #vgck -v
> vgck -- locking logical volume manager
> vgck -- finding all volume group(s)
> vgck -- checking volume group name "tripserv_vol"
> vgck -- checking existence of volume group "tripserv_vol"
> vgck -- reading volume group data for "tripserv_vol" from lvmtab
> vgck -- checking volume group consistency of "tripserv_vol" in lvmtab
> vgck -- VGDA of "tripserv_vol" in lvmtab is consistent
> vgck -- reading volume group data for "tripserv_vol" from physical volume(s)
> vgck -- checking volume group consistency of "tripserv_vol" on physical volumes
> vgck -- VGDA of "tripserv_vol" on physical volumes is consistent
> vgck -- unlocking logical volume manager
>
> # vgdisplay
> --- Volume group ---
> VG Name tripserv_vol
> VG Access read/write
> VG Status available/resizable
> VG # 0
> MAX LV 255
> Cur LV 22
> Open LV 1
> MAX LV Size 255.99 GB
> Max PV 255
> Cur PV 4
> Act PV 4
> VG Size 188.13 GB
> PE Size 4 MB
> Total PE 48162
> Alloc PE / Size 43220 / 168.83 GB
> Free PE / Size 4942 / 19.30 GB
> VG UUID KDiCWx-ae2w-oDnx-Hl5O-Amhd-fIM3-y51bIX
>
> # vgscan -v
> vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
> vgscan -- creating empty "/etc/lvmtab" and "/etc/lvmtab.d"
> vgscan -- reading all physical volumes (this may take a while...)
> vgscan -- scanning for all active volume group(s) first
> vgscan -- found active volume group "tripserv_vol"
> vgscan -- reading data of volume group "tripserv_vol" from physical volume(s)
> vgscan -- inserting "tripserv_vol" into lvmtab
> vgscan -- backing up volume group "tripserv_vol"
> vgscan -- checking volume group name "tripserv_vol"
> vgscan -- checking volume group consistency of "tripserv_vol"
> vgscan -- checking existence of "/etc/lvmtab.d"
> vgscan -- storing volume group data of "tripserv_vol" in "/etc/lvmtab.d/tripserv_vol.tmp"
> vgscan -- storing physical volume data of "tripserv_vol" in "/etc/lvmtab.d/tripserv_vol.tmp"
> vgscan -- storing logical volume data of volume group "tripserv_vol" in "/etc/lvmtab.d/tripserv_vol.tmp"
> vgscan -- renaming "/etc/lvmtab.d/tripserv_vol.tmp" to "/etc/lvmtab.d/tripserv_vol"
> vgscan -- removing special files and directory for volume group "tripserv_vol"
> vgscan -- creating directory and group character special file for "tripserv_vol"
> vgscan -- creating block device special files for tripserv_vol
> vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
> vgscan -- WARNING: This program does not do a VGDA backup of your volume group
>
> #lvscan
> lvscan -- ACTIVE Original "/dev/tripserv_vol/docu" [512 MB] striped[4]
> lvscan -- ACTIVE Original "/dev/tripserv_vol/install" [10 GB] striped[4]
> lvscan -- ACTIVE Original "/dev/tripserv_vol/pages" [20 GB] striped[4]
> lvscan -- ACTIVE "/dev/tripserv_vol/gfx" [10 GB] striped[4]
> lvscan -- ACTIVE "/dev/tripserv_vol/sfx" [10 GB] striped[4]
> lvscan -- ACTIVE "/dev/tripserv_vol/people" [20 GB] striped[4]
> lvscan -- ACTIVE Original "/dev/tripserv_vol/dim" [2 GB] striped[4]
> lvscan -- ACTIVE "/dev/tripserv_vol/mp3" [20 GB] striped[4]
> lvscan -- ACTIVE "/dev/tripserv_vol/applications" [2 GB] striped[4]
> lvscan -- ACTIVE Original "/dev/tripserv_vol/code" [512 MB] striped[4]
> lvscan -- ACTIVE "/dev/tripserv_vol/dumpdir" [10 GB] striped[4]
> lvscan -- ACTIVE Original "/dev/tripserv_vol/homes" [10 GB] striped[4]
> lvscan -- ACTIVE Original "/dev/tripserv_vol/info" [5 GB] striped[4]
> lvscan -- ACTIVE "/dev/tripserv_vol/log" [252 MB] striped[3]
> lvscan -- ACTIVE "/dev/tripserv_vol/store" [608 MB] striped[4]
> lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/docusnap" [492.19 MB] of /dev/tripserv_vol/docu
> lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/installsnap" [9.84 GB] of /dev/tripserv_vol/install
> lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/dimsnap" [1.97 GB] of /dev/tripserv_vol/dim
> lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/codesnap" [504 MB] of /dev/tripserv_vol/code
> lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/pagessnap" [19.69 GB] of /dev/tripserv_vol/pages
> lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/infosnap" [4.92 GB] of /dev/tripserv_vol/info
> lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/homessnap" [9.84 GB] of /dev/tripserv_vol/homes
> lvscan -- 22 logical volumes with 168.08 GB total in 1 volume group
> lvscan -- 22 active logical volumes
>
> # lvdisplay /dev/tripserv_vol/docu
> --- Logical volume ---
> LV Name /dev/tripserv_vol/docu
> VG Name tripserv_vol
> LV Write Access read/write
> LV snapshot status source of
> /dev/tripserv_vol/docusnap [active]
> LV Status available
> LV # 1
> # open 1
> LV Size 512 MB
> Current LE 128
> Allocated LE 128
> Stripes 4
> Stripe size (KByte) 4
> Allocation next free
> Read ahead sectors 120
> Block device 58:0
>
> # lvdisplay /dev/tripserv_vol/people
> --- Logical volume ---
> LV Name /dev/tripserv_vol/people
> VG Name tripserv_vol
> LV Write Access read/write
> LV Status available
> LV # 6
> # open 0
> LV Size 20 GB
> Current LE 5120
> Allocated LE 5120
> Stripes 4
> Stripe size (KByte) 4
> Allocation next free
> Read ahead sectors 120
> Block device 58:5
>
> # lvdisplay /dev/tripserv_vol/pages
> --- Logical volume ---
> LV Name /dev/tripserv_vol/pages
> VG Name tripserv_vol
> LV Write Access read/write
> LV snapshot status source of
> /dev/tripserv_vol/pagessnap [active]
> LV Status available
> LV # 3
> # open 0
> LV Size 20 GB
> Current LE 5120
> Allocated LE 5120
> Stripes 4
> Stripe size (KByte) 4
> Allocation next free
> Read ahead sectors 120
> Block device 58:2
>
> tripserv:/# lvdisplay /dev/tripserv_vol/pagessnap
> --- Logical volume ---
> LV Name /dev/tripserv_vol/pagessnap
> VG Name tripserv_vol
> LV Write Access read only
> LV snapshot status active destination for /dev/tripserv_vol/pages
> LV Status available
> LV # 20
> # open 0
> LV Size 20 GB
> Current LE 5120
> Allocated LE 5120
> snapshot chunk size 64 KB
> Allocated to snapshot 0.00% [0/19.69 GB]
> Allocated to COW-table 320 MB
> Stripes 4
> Stripe size (KByte) 4
> Allocation next free
> Read ahead sectors 120
> Block device 58:19
>
> # lvdisplay /dev/tripserv_vol/docusnap
> --- Logical volume ---
> LV Name /dev/tripserv_vol/docusnap
> VG Name tripserv_vol
> LV Write Access read only
> LV snapshot status active destination for /dev/tripserv_vol/docu
> LV Status available
> LV # 16
> # open 0
> LV Size 512 MB
> Current LE 128
> Allocated LE 128
> snapshot chunk size 64 KB
> Allocated to snapshot 0.05% [256 KB/492.19 MB]
> Allocated to COW-table 7.81 MB
> Stripes 4
> Stripe size (KByte) 4
> Allocation next free
> Read ahead sectors 120
> Block device 58:15
>
> So it all looks good!
*** 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-lvm] Help! unable to mount lv's - can't see why!
2002-09-18 6:37 [linux-lvm] Help! unable to mount lv's - can't see why! Robin Edgar - Tripany
2002-09-18 8:20 ` Heinz J . Mauelshagen
@ 2002-09-18 8:27 ` Robin Edgar - Tripany
2002-09-18 9:01 ` Heinz J . Mauelshagen
1 sibling, 1 reply; 14+ messages in thread
From: Robin Edgar - Tripany @ 2002-09-18 8:27 UTC (permalink / raw)
To: linux-lvm
[-- Attachment #1: Type: text/plain, Size: 12602 bytes --]
I've discovered that there is a problem with /all/ the superblocks except for those of the /docu lv (see below). It does lead me to another question though - only one of the HDs crashed: is it possible that LVM wrote all the superblocks on 1 HD?! If so this seems like a pretty serious bug in LVM...
Robin
./tune2fs -l /dev/tripserv_vol/docu
tune2fs 1.28 (31-Aug-2002)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 7746644b-c83d-447f-9562-18dff7634d94
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype needs_recovery sparse_super
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 131072
Block count: 524288
Reserved block count: 26214
Free blocks: 318873
Free inodes: 129020
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 2048
Inode blocks per group: 256
Last mount time: Wed Sep 18 17:13:48 2002
Last write time: Wed Sep 18 17:13:48 2002
Mount count: 33
Maximum mount count: 25
Last checked: Sun Mar 3 20:45:33 2002
Check interval: 15552000 (6 months)
Next check after: Fri Aug 30 21:45:33 2002
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal UUID: <none>
Journal inode: 8
Journal device: 0x0000
First orphan inode: 0
# ./tune2fs -l /dev/tripserv_vol/pages
tune2fs 1.28 (31-Aug-2002)
./tune2fs: Bad magic number in super-block while trying to open /dev/tripserv_vol/pages
Couldn't find valid filesystem superblock.
You have new mail in /var/spool/mail/root
# mke2fs -n /dev/tripserv_vol/pages
mke2fs 1.27 (8-Mar-2002)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
2621440 inodes, 5242880 blocks
262144 blocks (5.00%) reserved for the super user
First data block=0
160 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
----- Original Message -----
From: Robin Edgar - Tripany
To: linux-lvm@sistina.com
Sent: Wednesday, September 18, 2002 2:07 PM
Subject: [linux-lvm] Help! unable to mount lv's - can't see why!
Hi,
I had 4 (ide) disks in an array (and 1 vg) of which one (hde) broke. As I was not too sure of the stability of the system, I decided to do a dd of the disk byte by byte to another identical disk. After this was done (with loads of sector unreadable errors) I replaced the old disk with the new disk, rebooted the system and by all standards all seems well (see below):
Unfortunately, only the /dev/tripserv_vol/docu will mount well!
/dev/tripserv_vol/pages gives the following error:
# mount /dev/tripserv_vol/pages /c
mount: you must specify the filesystem type
# mount /dev/tripserv_vol/pages /c -t ext3
mount: wrong fs type, bad option, bad superblock on /dev/tripserv_vol/pages,
or too many mounted file systems
Anyone have any ideas why it won't mount?!
Cheers,
Robin Edgar
#pvscan:
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE PV "/dev/hdg1" of VG "tripserv_vol" [38.16 GB / 7.93 GB free]
pvscan -- ACTIVE PV "/dev/hdh1" of VG "tripserv_vol" [38.16 GB / 8.01 GB free]
pvscan -- ACTIVE PV "/dev/hde1" of VG "tripserv_vol" [55.91 GB / 0 free]
pvscan -- ACTIVE PV "/dev/hdf1" of VG "tripserv_vol" [55.91 GB / 3.37 GB free]
pvscan -- total: 4 [188.16 GB] / in use: 4 [188.16 GB] / in no VG: 0 [0]
(identical output to before changing the disks around)
#pvdisplay /dev/hde1
--- Physical volume ---
PV Name /dev/hde1
VG Name tripserv_vol
PV Size 55.92 GB [117266625 secs] / NOT usable 4.18 MB [LVM: 179 KB]
PV# 1
PV Status available
Allocatable yes (but full)
Cur LV 20
PE Size (KByte) 4096
Total PE 14313
Free PE 0
Allocated PE 14313
PV UUID KCIKwa-3lvx-k7bj-27ks-hGlI-oZRo-5q7CjM
(also identical)
#vgck -v
vgck -- locking logical volume manager
vgck -- finding all volume group(s)
vgck -- checking volume group name "tripserv_vol"
vgck -- checking existence of volume group "tripserv_vol"
vgck -- reading volume group data for "tripserv_vol" from lvmtab
vgck -- checking volume group consistency of "tripserv_vol" in lvmtab
vgck -- VGDA of "tripserv_vol" in lvmtab is consistent
vgck -- reading volume group data for "tripserv_vol" from physical volume(s)
vgck -- checking volume group consistency of "tripserv_vol" on physical volumes
vgck -- VGDA of "tripserv_vol" on physical volumes is consistent
vgck -- unlocking logical volume manager
# vgdisplay
--- Volume group ---
VG Name tripserv_vol
VG Access read/write
VG Status available/resizable
VG # 0
MAX LV 255
Cur LV 22
Open LV 1
MAX LV Size 255.99 GB
Max PV 255
Cur PV 4
Act PV 4
VG Size 188.13 GB
PE Size 4 MB
Total PE 48162
Alloc PE / Size 43220 / 168.83 GB
Free PE / Size 4942 / 19.30 GB
VG UUID KDiCWx-ae2w-oDnx-Hl5O-Amhd-fIM3-y51bIX
# vgscan -v
vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
vgscan -- creating empty "/etc/lvmtab" and "/etc/lvmtab.d"
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- scanning for all active volume group(s) first
vgscan -- found active volume group "tripserv_vol"
vgscan -- reading data of volume group "tripserv_vol" from physical volume(s)
vgscan -- inserting "tripserv_vol" into lvmtab
vgscan -- backing up volume group "tripserv_vol"
vgscan -- checking volume group name "tripserv_vol"
vgscan -- checking volume group consistency of "tripserv_vol"
vgscan -- checking existence of "/etc/lvmtab.d"
vgscan -- storing volume group data of "tripserv_vol" in "/etc/lvmtab.d/tripserv_vol.tmp"
vgscan -- storing physical volume data of "tripserv_vol" in "/etc/lvmtab.d/tripserv_vol.tmp"
vgscan -- storing logical volume data of volume group "tripserv_vol" in "/etc/lvmtab.d/tripserv_vol.tmp"
vgscan -- renaming "/etc/lvmtab.d/tripserv_vol.tmp" to "/etc/lvmtab.d/tripserv_vol"
vgscan -- removing special files and directory for volume group "tripserv_vol"
vgscan -- creating directory and group character special file for "tripserv_vol"
vgscan -- creating block device special files for tripserv_vol
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
vgscan -- WARNING: This program does not do a VGDA backup of your volume group
#lvscan
lvscan -- ACTIVE Original "/dev/tripserv_vol/docu" [512 MB] striped[4]
lvscan -- ACTIVE Original "/dev/tripserv_vol/install" [10 GB] striped[4]
lvscan -- ACTIVE Original "/dev/tripserv_vol/pages" [20 GB] striped[4]
lvscan -- ACTIVE "/dev/tripserv_vol/gfx" [10 GB] striped[4]
lvscan -- ACTIVE "/dev/tripserv_vol/sfx" [10 GB] striped[4]
lvscan -- ACTIVE "/dev/tripserv_vol/people" [20 GB] striped[4]
lvscan -- ACTIVE Original "/dev/tripserv_vol/dim" [2 GB] striped[4]
lvscan -- ACTIVE "/dev/tripserv_vol/mp3" [20 GB] striped[4]
lvscan -- ACTIVE "/dev/tripserv_vol/applications" [2 GB] striped[4]
lvscan -- ACTIVE Original "/dev/tripserv_vol/code" [512 MB] striped[4]
lvscan -- ACTIVE "/dev/tripserv_vol/dumpdir" [10 GB] striped[4]
lvscan -- ACTIVE Original "/dev/tripserv_vol/homes" [10 GB] striped[4]
lvscan -- ACTIVE Original "/dev/tripserv_vol/info" [5 GB] striped[4]
lvscan -- ACTIVE "/dev/tripserv_vol/log" [252 MB] striped[3]
lvscan -- ACTIVE "/dev/tripserv_vol/store" [608 MB] striped[4]
lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/docusnap" [492.19 MB] of /dev/tripserv_vol/docu
lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/installsnap" [9.84 GB] of /dev/tripserv_vol/install
lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/dimsnap" [1.97 GB] of /dev/tripserv_vol/dim
lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/codesnap" [504 MB] of /dev/tripserv_vol/code
lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/pagessnap" [19.69 GB] of /dev/tripserv_vol/pages
lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/infosnap" [4.92 GB] of /dev/tripserv_vol/info
lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/homessnap" [9.84 GB] of /dev/tripserv_vol/homes
lvscan -- 22 logical volumes with 168.08 GB total in 1 volume group
lvscan -- 22 active logical volumes
# lvdisplay /dev/tripserv_vol/docu
--- Logical volume ---
LV Name /dev/tripserv_vol/docu
VG Name tripserv_vol
LV Write Access read/write
LV snapshot status source of
/dev/tripserv_vol/docusnap [active]
LV Status available
LV # 1
# open 1
LV Size 512 MB
Current LE 128
Allocated LE 128
Stripes 4
Stripe size (KByte) 4
Allocation next free
Read ahead sectors 120
Block device 58:0
# lvdisplay /dev/tripserv_vol/people
--- Logical volume ---
LV Name /dev/tripserv_vol/people
VG Name tripserv_vol
LV Write Access read/write
LV Status available
LV # 6
# open 0
LV Size 20 GB
Current LE 5120
Allocated LE 5120
Stripes 4
Stripe size (KByte) 4
Allocation next free
Read ahead sectors 120
Block device 58:5
# lvdisplay /dev/tripserv_vol/pages
--- Logical volume ---
LV Name /dev/tripserv_vol/pages
VG Name tripserv_vol
LV Write Access read/write
LV snapshot status source of
/dev/tripserv_vol/pagessnap [active]
LV Status available
LV # 3
# open 0
LV Size 20 GB
Current LE 5120
Allocated LE 5120
Stripes 4
Stripe size (KByte) 4
Allocation next free
Read ahead sectors 120
Block device 58:2
tripserv:/# lvdisplay /dev/tripserv_vol/pagessnap
--- Logical volume ---
LV Name /dev/tripserv_vol/pagessnap
VG Name tripserv_vol
LV Write Access read only
LV snapshot status active destination for /dev/tripserv_vol/pages
LV Status available
LV # 20
# open 0
LV Size 20 GB
Current LE 5120
Allocated LE 5120
snapshot chunk size 64 KB
Allocated to snapshot 0.00% [0/19.69 GB]
Allocated to COW-table 320 MB
Stripes 4
Stripe size (KByte) 4
Allocation next free
Read ahead sectors 120
Block device 58:19
# lvdisplay /dev/tripserv_vol/docusnap
--- Logical volume ---
LV Name /dev/tripserv_vol/docusnap
VG Name tripserv_vol
LV Write Access read only
LV snapshot status active destination for /dev/tripserv_vol/docu
LV Status available
LV # 16
# open 0
LV Size 512 MB
Current LE 128
Allocated LE 128
snapshot chunk size 64 KB
Allocated to snapshot 0.05% [256 KB/492.19 MB]
Allocated to COW-table 7.81 MB
Stripes 4
Stripe size (KByte) 4
Allocation next free
Read ahead sectors 120
Block device 58:15
So it all looks good!
[-- Attachment #2: Type: text/html, Size: 25192 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-lvm] Help! unable to mount lv's - can't see why!
2002-09-18 8:27 ` Robin Edgar - Tripany
@ 2002-09-18 9:01 ` Heinz J . Mauelshagen
2002-09-18 9:17 ` Robin Edgar - Tripany
0 siblings, 1 reply; 14+ messages in thread
From: Heinz J . Mauelshagen @ 2002-09-18 9:01 UTC (permalink / raw)
To: linux-lvm
On Wed, Sep 18, 2002 at 03:56:36PM +0200, Robin Edgar - Tripany wrote:
> I've discovered that there is a problem with /all/ the superblocks except for those of the /docu lv (see below). It does lead me to another question though - only one of the HDs crashed: is it possible that LVM wrote all the superblocks on 1 HD?! If so this seems like a pretty serious bug in LVM...
No, LVs are just block devices with a certain amount of blocks.
It is up to the filesystem make tool what it lays out where.
In my other related email I mentioned "lvdisplay -v" to display the allocation
of extents. Maybe all the unmountable filesystems were in LVs on the failed
drive?
Regards,
Heinz -- The LVM Guy --
>
> Robin
>
> ./tune2fs -l /dev/tripserv_vol/docu
> tune2fs 1.28 (31-Aug-2002)
> Filesystem volume name: <none>
> Last mounted on: <not available>
> Filesystem UUID: 7746644b-c83d-447f-9562-18dff7634d94
> Filesystem magic number: 0xEF53
> Filesystem revision #: 1 (dynamic)
> Filesystem features: has_journal filetype needs_recovery sparse_super
> Filesystem state: clean
> Errors behavior: Continue
> Filesystem OS type: Linux
> Inode count: 131072
> Block count: 524288
> Reserved block count: 26214
> Free blocks: 318873
> Free inodes: 129020
> First block: 1
> Block size: 1024
> Fragment size: 1024
> Blocks per group: 8192
> Fragments per group: 8192
> Inodes per group: 2048
> Inode blocks per group: 256
> Last mount time: Wed Sep 18 17:13:48 2002
> Last write time: Wed Sep 18 17:13:48 2002
> Mount count: 33
> Maximum mount count: 25
> Last checked: Sun Mar 3 20:45:33 2002
> Check interval: 15552000 (6 months)
> Next check after: Fri Aug 30 21:45:33 2002
> Reserved blocks uid: 0 (user root)
> Reserved blocks gid: 0 (group root)
> First inode: 11
> Inode size: 128
> Journal UUID: <none>
> Journal inode: 8
> Journal device: 0x0000
> First orphan inode: 0
>
> # ./tune2fs -l /dev/tripserv_vol/pages
> tune2fs 1.28 (31-Aug-2002)
> ./tune2fs: Bad magic number in super-block while trying to open /dev/tripserv_vol/pages
> Couldn't find valid filesystem superblock.
> You have new mail in /var/spool/mail/root
>
> # mke2fs -n /dev/tripserv_vol/pages
> mke2fs 1.27 (8-Mar-2002)
> Filesystem label=
> OS type: Linux
> Block size=4096 (log=2)
> Fragment size=4096 (log=2)
> 2621440 inodes, 5242880 blocks
> 262144 blocks (5.00%) reserved for the super user
> First data block=0
> 160 block groups
> 32768 blocks per group, 32768 fragments per group
> 16384 inodes per group
> Superblock backups stored on blocks:
> 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
> 4096000
>
> ----- Original Message -----
> From: Robin Edgar - Tripany
> To: linux-lvm@sistina.com
> Sent: Wednesday, September 18, 2002 2:07 PM
> Subject: [linux-lvm] Help! unable to mount lv's - can't see why!
>
>
> Hi,
>
> I had 4 (ide) disks in an array (and 1 vg) of which one (hde) broke. As I was not too sure of the stability of the system, I decided to do a dd of the disk byte by byte to another identical disk. After this was done (with loads of sector unreadable errors) I replaced the old disk with the new disk, rebooted the system and by all standards all seems well (see below):
> Unfortunately, only the /dev/tripserv_vol/docu will mount well!
> /dev/tripserv_vol/pages gives the following error:
>
> # mount /dev/tripserv_vol/pages /c
> mount: you must specify the filesystem type
>
> # mount /dev/tripserv_vol/pages /c -t ext3
> mount: wrong fs type, bad option, bad superblock on /dev/tripserv_vol/pages,
> or too many mounted file systems
>
> Anyone have any ideas why it won't mount?!
>
> Cheers,
> Robin Edgar
>
> #pvscan:
> pvscan -- reading all physical volumes (this may take a while...)
> pvscan -- ACTIVE PV "/dev/hdg1" of VG "tripserv_vol" [38.16 GB / 7.93 GB free]
> pvscan -- ACTIVE PV "/dev/hdh1" of VG "tripserv_vol" [38.16 GB / 8.01 GB free]
> pvscan -- ACTIVE PV "/dev/hde1" of VG "tripserv_vol" [55.91 GB / 0 free]
> pvscan -- ACTIVE PV "/dev/hdf1" of VG "tripserv_vol" [55.91 GB / 3.37 GB free]
> pvscan -- total: 4 [188.16 GB] / in use: 4 [188.16 GB] / in no VG: 0 [0]
>
> (identical output to before changing the disks around)
>
> #pvdisplay /dev/hde1
> --- Physical volume ---
> PV Name /dev/hde1
> VG Name tripserv_vol
> PV Size 55.92 GB [117266625 secs] / NOT usable 4.18 MB [LVM: 179 KB]
> PV# 1
> PV Status available
> Allocatable yes (but full)
> Cur LV 20
> PE Size (KByte) 4096
> Total PE 14313
> Free PE 0
> Allocated PE 14313
> PV UUID KCIKwa-3lvx-k7bj-27ks-hGlI-oZRo-5q7CjM
>
> (also identical)
>
> #vgck -v
> vgck -- locking logical volume manager
> vgck -- finding all volume group(s)
> vgck -- checking volume group name "tripserv_vol"
> vgck -- checking existence of volume group "tripserv_vol"
> vgck -- reading volume group data for "tripserv_vol" from lvmtab
> vgck -- checking volume group consistency of "tripserv_vol" in lvmtab
> vgck -- VGDA of "tripserv_vol" in lvmtab is consistent
> vgck -- reading volume group data for "tripserv_vol" from physical volume(s)
> vgck -- checking volume group consistency of "tripserv_vol" on physical volumes
> vgck -- VGDA of "tripserv_vol" on physical volumes is consistent
> vgck -- unlocking logical volume manager
>
> # vgdisplay
> --- Volume group ---
> VG Name tripserv_vol
> VG Access read/write
> VG Status available/resizable
> VG # 0
> MAX LV 255
> Cur LV 22
> Open LV 1
> MAX LV Size 255.99 GB
> Max PV 255
> Cur PV 4
> Act PV 4
> VG Size 188.13 GB
> PE Size 4 MB
> Total PE 48162
> Alloc PE / Size 43220 / 168.83 GB
> Free PE / Size 4942 / 19.30 GB
> VG UUID KDiCWx-ae2w-oDnx-Hl5O-Amhd-fIM3-y51bIX
>
> # vgscan -v
> vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
> vgscan -- creating empty "/etc/lvmtab" and "/etc/lvmtab.d"
> vgscan -- reading all physical volumes (this may take a while...)
> vgscan -- scanning for all active volume group(s) first
> vgscan -- found active volume group "tripserv_vol"
> vgscan -- reading data of volume group "tripserv_vol" from physical volume(s)
> vgscan -- inserting "tripserv_vol" into lvmtab
> vgscan -- backing up volume group "tripserv_vol"
> vgscan -- checking volume group name "tripserv_vol"
> vgscan -- checking volume group consistency of "tripserv_vol"
> vgscan -- checking existence of "/etc/lvmtab.d"
> vgscan -- storing volume group data of "tripserv_vol" in "/etc/lvmtab.d/tripserv_vol.tmp"
> vgscan -- storing physical volume data of "tripserv_vol" in "/etc/lvmtab.d/tripserv_vol.tmp"
> vgscan -- storing logical volume data of volume group "tripserv_vol" in "/etc/lvmtab.d/tripserv_vol.tmp"
> vgscan -- renaming "/etc/lvmtab.d/tripserv_vol.tmp" to "/etc/lvmtab.d/tripserv_vol"
> vgscan -- removing special files and directory for volume group "tripserv_vol"
> vgscan -- creating directory and group character special file for "tripserv_vol"
> vgscan -- creating block device special files for tripserv_vol
> vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
> vgscan -- WARNING: This program does not do a VGDA backup of your volume group
>
> #lvscan
> lvscan -- ACTIVE Original "/dev/tripserv_vol/docu" [512 MB] striped[4]
> lvscan -- ACTIVE Original "/dev/tripserv_vol/install" [10 GB] striped[4]
> lvscan -- ACTIVE Original "/dev/tripserv_vol/pages" [20 GB] striped[4]
> lvscan -- ACTIVE "/dev/tripserv_vol/gfx" [10 GB] striped[4]
> lvscan -- ACTIVE "/dev/tripserv_vol/sfx" [10 GB] striped[4]
> lvscan -- ACTIVE "/dev/tripserv_vol/people" [20 GB] striped[4]
> lvscan -- ACTIVE Original "/dev/tripserv_vol/dim" [2 GB] striped[4]
> lvscan -- ACTIVE "/dev/tripserv_vol/mp3" [20 GB] striped[4]
> lvscan -- ACTIVE "/dev/tripserv_vol/applications" [2 GB] striped[4]
> lvscan -- ACTIVE Original "/dev/tripserv_vol/code" [512 MB] striped[4]
> lvscan -- ACTIVE "/dev/tripserv_vol/dumpdir" [10 GB] striped[4]
> lvscan -- ACTIVE Original "/dev/tripserv_vol/homes" [10 GB] striped[4]
> lvscan -- ACTIVE Original "/dev/tripserv_vol/info" [5 GB] striped[4]
> lvscan -- ACTIVE "/dev/tripserv_vol/log" [252 MB] striped[3]
> lvscan -- ACTIVE "/dev/tripserv_vol/store" [608 MB] striped[4]
> lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/docusnap" [492.19 MB] of /dev/tripserv_vol/docu
> lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/installsnap" [9.84 GB] of /dev/tripserv_vol/install
> lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/dimsnap" [1.97 GB] of /dev/tripserv_vol/dim
> lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/codesnap" [504 MB] of /dev/tripserv_vol/code
> lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/pagessnap" [19.69 GB] of /dev/tripserv_vol/pages
> lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/infosnap" [4.92 GB] of /dev/tripserv_vol/info
> lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/homessnap" [9.84 GB] of /dev/tripserv_vol/homes
> lvscan -- 22 logical volumes with 168.08 GB total in 1 volume group
> lvscan -- 22 active logical volumes
>
> # lvdisplay /dev/tripserv_vol/docu
> --- Logical volume ---
> LV Name /dev/tripserv_vol/docu
> VG Name tripserv_vol
> LV Write Access read/write
> LV snapshot status source of
> /dev/tripserv_vol/docusnap [active]
> LV Status available
> LV # 1
> # open 1
> LV Size 512 MB
> Current LE 128
> Allocated LE 128
> Stripes 4
> Stripe size (KByte) 4
> Allocation next free
> Read ahead sectors 120
> Block device 58:0
>
> # lvdisplay /dev/tripserv_vol/people
> --- Logical volume ---
> LV Name /dev/tripserv_vol/people
> VG Name tripserv_vol
> LV Write Access read/write
> LV Status available
> LV # 6
> # open 0
> LV Size 20 GB
> Current LE 5120
> Allocated LE 5120
> Stripes 4
> Stripe size (KByte) 4
> Allocation next free
> Read ahead sectors 120
> Block device 58:5
>
> # lvdisplay /dev/tripserv_vol/pages
> --- Logical volume ---
> LV Name /dev/tripserv_vol/pages
> VG Name tripserv_vol
> LV Write Access read/write
> LV snapshot status source of
> /dev/tripserv_vol/pagessnap [active]
> LV Status available
> LV # 3
> # open 0
> LV Size 20 GB
> Current LE 5120
> Allocated LE 5120
> Stripes 4
> Stripe size (KByte) 4
> Allocation next free
> Read ahead sectors 120
> Block device 58:2
>
> tripserv:/# lvdisplay /dev/tripserv_vol/pagessnap
> --- Logical volume ---
> LV Name /dev/tripserv_vol/pagessnap
> VG Name tripserv_vol
> LV Write Access read only
> LV snapshot status active destination for /dev/tripserv_vol/pages
> LV Status available
> LV # 20
> # open 0
> LV Size 20 GB
> Current LE 5120
> Allocated LE 5120
> snapshot chunk size 64 KB
> Allocated to snapshot 0.00% [0/19.69 GB]
> Allocated to COW-table 320 MB
> Stripes 4
> Stripe size (KByte) 4
> Allocation next free
> Read ahead sectors 120
> Block device 58:19
>
> # lvdisplay /dev/tripserv_vol/docusnap
> --- Logical volume ---
> LV Name /dev/tripserv_vol/docusnap
> VG Name tripserv_vol
> LV Write Access read only
> LV snapshot status active destination for /dev/tripserv_vol/docu
> LV Status available
> LV # 16
> # open 0
> LV Size 512 MB
> Current LE 128
> Allocated LE 128
> snapshot chunk size 64 KB
> Allocated to snapshot 0.05% [256 KB/492.19 MB]
> Allocated to COW-table 7.81 MB
> Stripes 4
> Stripe size (KByte) 4
> Allocation next free
> Read ahead sectors 120
> Block device 58:15
>
> So it all looks good!
*** 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-lvm] Help! unable to mount lv's - can't see why!
2002-09-18 8:20 ` Heinz J . Mauelshagen
@ 2002-09-18 9:07 ` Robin Edgar - Tripany
2002-09-19 5:10 ` Heinz J . Mauelshagen
0 siblings, 1 reply; 14+ messages in thread
From: Robin Edgar - Tripany @ 2002-09-18 9:07 UTC (permalink / raw)
To: linux-lvm
Hi Heinz,
Thanks for the help so far!
How can I find out the blocksize of my lv's? So far I've tried e2fsck on the
lv's using the mke2fs -n /dev/tripserv_vol/pages, for all blocksizes (-b
1024, 2048, 4096) but none of the superblocks respond to fsck. The only
thing I can think of now is letting fsck rebuild the superblock, but I have
to be sure of the blocksize for it to have any chance of success. Building
the lv's, I followed the following steps:
pvcreate /dev/hde
/dev/hdf
/dev/hdg
/dev/hdh
vgcreate tripserv_vol /dev/hde /dev/hdf /dev/hdg /dev/hdh
lvcreate -i3 -I4 -L100M -nvolumename tripserv_vol
mke2fs -j -Lfslabel /dev/tripserv_vol/volumename
Cheers,
Robin
----- Original Message -----
From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
To: <linux-lvm@sistina.com>
Sent: Wednesday, September 18, 2002 3:18 PM
Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
> On Wed, Sep 18, 2002 at 02:07:18PM +0200, Robin Edgar - Tripany wrote:
> > Hi,
> >
> > I had 4 (ide) disks in an array (and 1 vg) of which one (hde) broke. As
I was not too sure of the stability of the system, I decided to do a dd of
the disk byte by byte to another identical disk. After this was done (with
loads of sector unreadable errors) I replaced the old disk with the new
disk, rebooted the system and by all standards all seems well (see below):
>
> Robin,
>
> lots of read errors during dd likely left you with a corrupted primary
> superblock of the filesystem.
>
> > Unfortunately, only the /dev/tripserv_vol/docu will mount well!
> > /dev/tripserv_vol/pages gives the following error:
> >
> > # mount /dev/tripserv_vol/pages /c
> > mount: you must specify the filesystem type
> >
> > # mount /dev/tripserv_vol/pages /c -t ext3
> > mount: wrong fs type, bad option, bad superblock on
/dev/tripserv_vol/pages,
> > or too many mounted file systems
> >
> > Anyone have any ideas why it won't mount?!
>
> You need to figure out, if /dev/tripserv_vol/docu doesn't have *any*
extents
> allocated on the replaced disk. Try "lvdisplay -v /dev/tripserv_vol/docu"
> to achive this. If it has, you'll likely find corrupted files in this one
> too.
>
>
> For the failing mount you might want to try
>
> "mount -r -osb=$ALTERNATE_SUPERBLOCK /dev/tripserv_vol/pages /c".
>
> In case you've got a logical 4k block size of the filesystem,
> ALTERNATE_SUPERBLOCK=131072 would access the first backup copy.
>
> See "man mount" and look for the ext2 mount option "sb=" for more
information.
>
> In case you have success with using a backup superblock this way, you need
to
> backup all files you can access successfully first, then recreate the
filesystem
> and restore. It is unlikely in the case of lots of read errors during dd,
that
> a fsck will help you. You'll probably end up with piles of lost+found
entries.
>
> Regards,
> Heinz -- The LVM Guy --
>
>
> >
> > Cheers,
> > Robin Edgar
> >
> > #pvscan:
> > pvscan -- reading all physical volumes (this may take a while...)
> > pvscan -- ACTIVE PV "/dev/hdg1" of VG "tripserv_vol" [38.16 GB / 7.93
GB free]
> > pvscan -- ACTIVE PV "/dev/hdh1" of VG "tripserv_vol" [38.16 GB / 8.01
GB free]
> > pvscan -- ACTIVE PV "/dev/hde1" of VG "tripserv_vol" [55.91 GB / 0
free]
> > pvscan -- ACTIVE PV "/dev/hdf1" of VG "tripserv_vol" [55.91 GB / 3.37
GB free]
> > pvscan -- total: 4 [188.16 GB] / in use: 4 [188.16 GB] / in no VG: 0 [0]
> >
> > (identical output to before changing the disks around)
> >
> > #pvdisplay /dev/hde1
> > --- Physical volume ---
> > PV Name /dev/hde1
> > VG Name tripserv_vol
> > PV Size 55.92 GB [117266625 secs] / NOT usable 4.18 MB
[LVM: 179 KB]
> > PV# 1
> > PV Status available
> > Allocatable yes (but full)
> > Cur LV 20
> > PE Size (KByte) 4096
> > Total PE 14313
> > Free PE 0
> > Allocated PE 14313
> > PV UUID KCIKwa-3lvx-k7bj-27ks-hGlI-oZRo-5q7CjM
> >
> > (also identical)
> >
> > #vgck -v
> > vgck -- locking logical volume manager
> > vgck -- finding all volume group(s)
> > vgck -- checking volume group name "tripserv_vol"
> > vgck -- checking existence of volume group "tripserv_vol"
> > vgck -- reading volume group data for "tripserv_vol" from lvmtab
> > vgck -- checking volume group consistency of "tripserv_vol" in lvmtab
> > vgck -- VGDA of "tripserv_vol" in lvmtab is consistent
> > vgck -- reading volume group data for "tripserv_vol" from physical
volume(s)
> > vgck -- checking volume group consistency of "tripserv_vol" on physical
volumes
> > vgck -- VGDA of "tripserv_vol" on physical volumes is consistent
> > vgck -- unlocking logical volume manager
> >
> > # vgdisplay
> > --- Volume group ---
> > VG Name tripserv_vol
> > VG Access read/write
> > VG Status available/resizable
> > VG # 0
> > MAX LV 255
> > Cur LV 22
> > Open LV 1
> > MAX LV Size 255.99 GB
> > Max PV 255
> > Cur PV 4
> > Act PV 4
> > VG Size 188.13 GB
> > PE Size 4 MB
> > Total PE 48162
> > Alloc PE / Size 43220 / 168.83 GB
> > Free PE / Size 4942 / 19.30 GB
> > VG UUID KDiCWx-ae2w-oDnx-Hl5O-Amhd-fIM3-y51bIX
> >
> > # vgscan -v
> > vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
> > vgscan -- creating empty "/etc/lvmtab" and "/etc/lvmtab.d"
> > vgscan -- reading all physical volumes (this may take a while...)
> > vgscan -- scanning for all active volume group(s) first
> > vgscan -- found active volume group "tripserv_vol"
> > vgscan -- reading data of volume group "tripserv_vol" from physical
volume(s)
> > vgscan -- inserting "tripserv_vol" into lvmtab
> > vgscan -- backing up volume group "tripserv_vol"
> > vgscan -- checking volume group name "tripserv_vol"
> > vgscan -- checking volume group consistency of "tripserv_vol"
> > vgscan -- checking existence of "/etc/lvmtab.d"
> > vgscan -- storing volume group data of "tripserv_vol" in
"/etc/lvmtab.d/tripserv_vol.tmp"
> > vgscan -- storing physical volume data of "tripserv_vol" in
"/etc/lvmtab.d/tripserv_vol.tmp"
> > vgscan -- storing logical volume data of volume group "tripserv_vol" in
"/etc/lvmtab.d/tripserv_vol.tmp"
> > vgscan -- renaming "/etc/lvmtab.d/tripserv_vol.tmp" to
"/etc/lvmtab.d/tripserv_vol"
> > vgscan -- removing special files and directory for volume group
"tripserv_vol"
> > vgscan -- creating directory and group character special file for
"tripserv_vol"
> > vgscan -- creating block device special files for tripserv_vol
> > vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
> > vgscan -- WARNING: This program does not do a VGDA backup of your volume
group
> >
> > #lvscan
> > lvscan -- ACTIVE Original "/dev/tripserv_vol/docu" [512 MB] striped[4]
> > lvscan -- ACTIVE Original "/dev/tripserv_vol/install" [10 GB]
striped[4]
> > lvscan -- ACTIVE Original "/dev/tripserv_vol/pages" [20 GB] striped[4]
> > lvscan -- ACTIVE "/dev/tripserv_vol/gfx" [10 GB] striped[4]
> > lvscan -- ACTIVE "/dev/tripserv_vol/sfx" [10 GB] striped[4]
> > lvscan -- ACTIVE "/dev/tripserv_vol/people" [20 GB]
striped[4]
> > lvscan -- ACTIVE Original "/dev/tripserv_vol/dim" [2 GB] striped[4]
> > lvscan -- ACTIVE "/dev/tripserv_vol/mp3" [20 GB] striped[4]
> > lvscan -- ACTIVE "/dev/tripserv_vol/applications" [2 GB]
striped[4]
> > lvscan -- ACTIVE Original "/dev/tripserv_vol/code" [512 MB] striped[4]
> > lvscan -- ACTIVE "/dev/tripserv_vol/dumpdir" [10 GB]
striped[4]
> > lvscan -- ACTIVE Original "/dev/tripserv_vol/homes" [10 GB] striped[4]
> > lvscan -- ACTIVE Original "/dev/tripserv_vol/info" [5 GB] striped[4]
> > lvscan -- ACTIVE "/dev/tripserv_vol/log" [252 MB] striped[3]
> > lvscan -- ACTIVE "/dev/tripserv_vol/store" [608 MB]
striped[4]
> > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/docusnap" [492.19 MB] of
/dev/tripserv_vol/docu
> > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/installsnap" [9.84 GB] of
/dev/tripserv_vol/install
> > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/dimsnap" [1.97 GB] of
/dev/tripserv_vol/dim
> > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/codesnap" [504 MB] of
/dev/tripserv_vol/code
> > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/pagessnap" [19.69 GB] of
/dev/tripserv_vol/pages
> > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/infosnap" [4.92 GB] of
/dev/tripserv_vol/info
> > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/homessnap" [9.84 GB] of
/dev/tripserv_vol/homes
> > lvscan -- 22 logical volumes with 168.08 GB total in 1 volume group
> > lvscan -- 22 active logical volumes
> >
> > # lvdisplay /dev/tripserv_vol/docu
> > --- Logical volume ---
> > LV Name /dev/tripserv_vol/docu
> > VG Name tripserv_vol
> > LV Write Access read/write
> > LV snapshot status source of
> > /dev/tripserv_vol/docusnap [active]
> > LV Status available
> > LV # 1
> > # open 1
> > LV Size 512 MB
> > Current LE 128
> > Allocated LE 128
> > Stripes 4
> > Stripe size (KByte) 4
> > Allocation next free
> > Read ahead sectors 120
> > Block device 58:0
> >
> > # lvdisplay /dev/tripserv_vol/people
> > --- Logical volume ---
> > LV Name /dev/tripserv_vol/people
> > VG Name tripserv_vol
> > LV Write Access read/write
> > LV Status available
> > LV # 6
> > # open 0
> > LV Size 20 GB
> > Current LE 5120
> > Allocated LE 5120
> > Stripes 4
> > Stripe size (KByte) 4
> > Allocation next free
> > Read ahead sectors 120
> > Block device 58:5
> >
> > # lvdisplay /dev/tripserv_vol/pages
> > --- Logical volume ---
> > LV Name /dev/tripserv_vol/pages
> > VG Name tripserv_vol
> > LV Write Access read/write
> > LV snapshot status source of
> > /dev/tripserv_vol/pagessnap [active]
> > LV Status available
> > LV # 3
> > # open 0
> > LV Size 20 GB
> > Current LE 5120
> > Allocated LE 5120
> > Stripes 4
> > Stripe size (KByte) 4
> > Allocation next free
> > Read ahead sectors 120
> > Block device 58:2
> >
> > tripserv:/# lvdisplay /dev/tripserv_vol/pagessnap
> > --- Logical volume ---
> > LV Name /dev/tripserv_vol/pagessnap
> > VG Name tripserv_vol
> > LV Write Access read only
> > LV snapshot status active destination for /dev/tripserv_vol/pages
> > LV Status available
> > LV # 20
> > # open 0
> > LV Size 20 GB
> > Current LE 5120
> > Allocated LE 5120
> > snapshot chunk size 64 KB
> > Allocated to snapshot 0.00% [0/19.69 GB]
> > Allocated to COW-table 320 MB
> > Stripes 4
> > Stripe size (KByte) 4
> > Allocation next free
> > Read ahead sectors 120
> > Block device 58:19
> >
> > # lvdisplay /dev/tripserv_vol/docusnap
> > --- Logical volume ---
> > LV Name /dev/tripserv_vol/docusnap
> > VG Name tripserv_vol
> > LV Write Access read only
> > LV snapshot status active destination for /dev/tripserv_vol/docu
> > LV Status available
> > LV # 16
> > # open 0
> > LV Size 512 MB
> > Current LE 128
> > Allocated LE 128
> > snapshot chunk size 64 KB
> > Allocated to snapshot 0.05% [256 KB/492.19 MB]
> > Allocated to COW-table 7.81 MB
> > Stripes 4
> > Stripe size (KByte) 4
> > Allocation next free
> > Read ahead sectors 120
> > Block device 58:15
> >
> > So it all looks good!
>
> *** 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
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-lvm] Help! unable to mount lv's - can't see why!
2002-09-18 9:01 ` Heinz J . Mauelshagen
@ 2002-09-18 9:17 ` Robin Edgar - Tripany
2002-09-19 5:05 ` Heinz J . Mauelshagen
0 siblings, 1 reply; 14+ messages in thread
From: Robin Edgar - Tripany @ 2002-09-18 9:17 UTC (permalink / raw)
To: linux-lvm
Doing the lvdisplay -v shows that pv /dev/hde1 had bits of all of the lv's
on it (including the docu lv, which I *can* mount).
----- Original Message -----
From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
To: <linux-lvm@sistina.com>
Sent: Wednesday, September 18, 2002 3:59 PM
Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
> On Wed, Sep 18, 2002 at 03:56:36PM +0200, Robin Edgar - Tripany wrote:
> > I've discovered that there is a problem with /all/ the superblocks
except for those of the /docu lv (see below). It does lead me to another
question though - only one of the HDs crashed: is it possible that LVM wrote
all the superblocks on 1 HD?! If so this seems like a pretty serious bug in
LVM...
>
> No, LVs are just block devices with a certain amount of blocks.
> It is up to the filesystem make tool what it lays out where.
>
> In my other related email I mentioned "lvdisplay -v" to display the
allocation
> of extents. Maybe all the unmountable filesystems were in LVs on the
failed
> drive?
>
> Regards,
> Heinz -- The LVM Guy --
>
> >
> > Robin
> >
> > ./tune2fs -l /dev/tripserv_vol/docu
> > tune2fs 1.28 (31-Aug-2002)
> > Filesystem volume name: <none>
> > Last mounted on: <not available>
> > Filesystem UUID: 7746644b-c83d-447f-9562-18dff7634d94
> > Filesystem magic number: 0xEF53
> > Filesystem revision #: 1 (dynamic)
> > Filesystem features: has_journal filetype needs_recovery
sparse_super
> > Filesystem state: clean
> > Errors behavior: Continue
> > Filesystem OS type: Linux
> > Inode count: 131072
> > Block count: 524288
> > Reserved block count: 26214
> > Free blocks: 318873
> > Free inodes: 129020
> > First block: 1
> > Block size: 1024
> > Fragment size: 1024
> > Blocks per group: 8192
> > Fragments per group: 8192
> > Inodes per group: 2048
> > Inode blocks per group: 256
> > Last mount time: Wed Sep 18 17:13:48 2002
> > Last write time: Wed Sep 18 17:13:48 2002
> > Mount count: 33
> > Maximum mount count: 25
> > Last checked: Sun Mar 3 20:45:33 2002
> > Check interval: 15552000 (6 months)
> > Next check after: Fri Aug 30 21:45:33 2002
> > Reserved blocks uid: 0 (user root)
> > Reserved blocks gid: 0 (group root)
> > First inode: 11
> > Inode size: 128
> > Journal UUID: <none>
> > Journal inode: 8
> > Journal device: 0x0000
> > First orphan inode: 0
> >
> > # ./tune2fs -l /dev/tripserv_vol/pages
> > tune2fs 1.28 (31-Aug-2002)
> > ./tune2fs: Bad magic number in super-block while trying to open
/dev/tripserv_vol/pages
> > Couldn't find valid filesystem superblock.
> > You have new mail in /var/spool/mail/root
> >
> > # mke2fs -n /dev/tripserv_vol/pages
> > mke2fs 1.27 (8-Mar-2002)
> > Filesystem label=
> > OS type: Linux
> > Block size=4096 (log=2)
> > Fragment size=4096 (log=2)
> > 2621440 inodes, 5242880 blocks
> > 262144 blocks (5.00%) reserved for the super user
> > First data block=0
> > 160 block groups
> > 32768 blocks per group, 32768 fragments per group
> > 16384 inodes per group
> > Superblock backups stored on blocks:
> > 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
2654208,
> > 4096000
> >
> > ----- Original Message -----
> > From: Robin Edgar - Tripany
> > To: linux-lvm@sistina.com
> > Sent: Wednesday, September 18, 2002 2:07 PM
> > Subject: [linux-lvm] Help! unable to mount lv's - can't see why!
> >
> >
> > Hi,
> >
> > I had 4 (ide) disks in an array (and 1 vg) of which one (hde) broke.
As I was not too sure of the stability of the system, I decided to do a dd
of the disk byte by byte to another identical disk. After this was done
(with loads of sector unreadable errors) I replaced the old disk with the
new disk, rebooted the system and by all standards all seems well (see
below):
> > Unfortunately, only the /dev/tripserv_vol/docu will mount well!
> > /dev/tripserv_vol/pages gives the following error:
> >
> > # mount /dev/tripserv_vol/pages /c
> > mount: you must specify the filesystem type
> >
> > # mount /dev/tripserv_vol/pages /c -t ext3
> > mount: wrong fs type, bad option, bad superblock on
/dev/tripserv_vol/pages,
> > or too many mounted file systems
> >
> > Anyone have any ideas why it won't mount?!
> >
> > Cheers,
> > Robin Edgar
> >
> > #pvscan:
> > pvscan -- reading all physical volumes (this may take a while...)
> > pvscan -- ACTIVE PV "/dev/hdg1" of VG "tripserv_vol" [38.16 GB /
7.93 GB free]
> > pvscan -- ACTIVE PV "/dev/hdh1" of VG "tripserv_vol" [38.16 GB /
8.01 GB free]
> > pvscan -- ACTIVE PV "/dev/hde1" of VG "tripserv_vol" [55.91 GB / 0
free]
> > pvscan -- ACTIVE PV "/dev/hdf1" of VG "tripserv_vol" [55.91 GB /
3.37 GB free]
> > pvscan -- total: 4 [188.16 GB] / in use: 4 [188.16 GB] / in no VG: 0
[0]
> >
> > (identical output to before changing the disks around)
> >
> > #pvdisplay /dev/hde1
> > --- Physical volume ---
> > PV Name /dev/hde1
> > VG Name tripserv_vol
> > PV Size 55.92 GB [117266625 secs] / NOT usable 4.18 MB
[LVM: 179 KB]
> > PV# 1
> > PV Status available
> > Allocatable yes (but full)
> > Cur LV 20
> > PE Size (KByte) 4096
> > Total PE 14313
> > Free PE 0
> > Allocated PE 14313
> > PV UUID KCIKwa-3lvx-k7bj-27ks-hGlI-oZRo-5q7CjM
> >
> > (also identical)
> >
> > #vgck -v
> > vgck -- locking logical volume manager
> > vgck -- finding all volume group(s)
> > vgck -- checking volume group name "tripserv_vol"
> > vgck -- checking existence of volume group "tripserv_vol"
> > vgck -- reading volume group data for "tripserv_vol" from lvmtab
> > vgck -- checking volume group consistency of "tripserv_vol" in lvmtab
> > vgck -- VGDA of "tripserv_vol" in lvmtab is consistent
> > vgck -- reading volume group data for "tripserv_vol" from physical
volume(s)
> > vgck -- checking volume group consistency of "tripserv_vol" on
physical volumes
> > vgck -- VGDA of "tripserv_vol" on physical volumes is consistent
> > vgck -- unlocking logical volume manager
> >
> > # vgdisplay
> > --- Volume group ---
> > VG Name tripserv_vol
> > VG Access read/write
> > VG Status available/resizable
> > VG # 0
> > MAX LV 255
> > Cur LV 22
> > Open LV 1
> > MAX LV Size 255.99 GB
> > Max PV 255
> > Cur PV 4
> > Act PV 4
> > VG Size 188.13 GB
> > PE Size 4 MB
> > Total PE 48162
> > Alloc PE / Size 43220 / 168.83 GB
> > Free PE / Size 4942 / 19.30 GB
> > VG UUID KDiCWx-ae2w-oDnx-Hl5O-Amhd-fIM3-y51bIX
> >
> > # vgscan -v
> > vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
> > vgscan -- creating empty "/etc/lvmtab" and "/etc/lvmtab.d"
> > vgscan -- reading all physical volumes (this may take a while...)
> > vgscan -- scanning for all active volume group(s) first
> > vgscan -- found active volume group "tripserv_vol"
> > vgscan -- reading data of volume group "tripserv_vol" from physical
volume(s)
> > vgscan -- inserting "tripserv_vol" into lvmtab
> > vgscan -- backing up volume group "tripserv_vol"
> > vgscan -- checking volume group name "tripserv_vol"
> > vgscan -- checking volume group consistency of "tripserv_vol"
> > vgscan -- checking existence of "/etc/lvmtab.d"
> > vgscan -- storing volume group data of "tripserv_vol" in
"/etc/lvmtab.d/tripserv_vol.tmp"
> > vgscan -- storing physical volume data of "tripserv_vol" in
"/etc/lvmtab.d/tripserv_vol.tmp"
> > vgscan -- storing logical volume data of volume group "tripserv_vol"
in "/etc/lvmtab.d/tripserv_vol.tmp"
> > vgscan -- renaming "/etc/lvmtab.d/tripserv_vol.tmp" to
"/etc/lvmtab.d/tripserv_vol"
> > vgscan -- removing special files and directory for volume group
"tripserv_vol"
> > vgscan -- creating directory and group character special file for
"tripserv_vol"
> > vgscan -- creating block device special files for tripserv_vol
> > vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
> > vgscan -- WARNING: This program does not do a VGDA backup of your
volume group
> >
> > #lvscan
> > lvscan -- ACTIVE Original "/dev/tripserv_vol/docu" [512 MB]
striped[4]
> > lvscan -- ACTIVE Original "/dev/tripserv_vol/install" [10 GB]
striped[4]
> > lvscan -- ACTIVE Original "/dev/tripserv_vol/pages" [20 GB]
striped[4]
> > lvscan -- ACTIVE "/dev/tripserv_vol/gfx" [10 GB] striped[4]
> > lvscan -- ACTIVE "/dev/tripserv_vol/sfx" [10 GB] striped[4]
> > lvscan -- ACTIVE "/dev/tripserv_vol/people" [20 GB]
striped[4]
> > lvscan -- ACTIVE Original "/dev/tripserv_vol/dim" [2 GB] striped[4]
> > lvscan -- ACTIVE "/dev/tripserv_vol/mp3" [20 GB] striped[4]
> > lvscan -- ACTIVE "/dev/tripserv_vol/applications" [2 GB]
striped[4]
> > lvscan -- ACTIVE Original "/dev/tripserv_vol/code" [512 MB]
striped[4]
> > lvscan -- ACTIVE "/dev/tripserv_vol/dumpdir" [10 GB]
striped[4]
> > lvscan -- ACTIVE Original "/dev/tripserv_vol/homes" [10 GB]
striped[4]
> > lvscan -- ACTIVE Original "/dev/tripserv_vol/info" [5 GB] striped[4]
> > lvscan -- ACTIVE "/dev/tripserv_vol/log" [252 MB]
striped[3]
> > lvscan -- ACTIVE "/dev/tripserv_vol/store" [608 MB]
striped[4]
> > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/docusnap" [492.19 MB]
of /dev/tripserv_vol/docu
> > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/installsnap" [9.84 GB]
of /dev/tripserv_vol/install
> > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/dimsnap" [1.97 GB] of
/dev/tripserv_vol/dim
> > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/codesnap" [504 MB] of
/dev/tripserv_vol/code
> > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/pagessnap" [19.69 GB]
of /dev/tripserv_vol/pages
> > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/infosnap" [4.92 GB] of
/dev/tripserv_vol/info
> > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/homessnap" [9.84 GB] of
/dev/tripserv_vol/homes
> > lvscan -- 22 logical volumes with 168.08 GB total in 1 volume group
> > lvscan -- 22 active logical volumes
> >
> > # lvdisplay /dev/tripserv_vol/docu
> > --- Logical volume ---
> > LV Name /dev/tripserv_vol/docu
> > VG Name tripserv_vol
> > LV Write Access read/write
> > LV snapshot status source of
> > /dev/tripserv_vol/docusnap [active]
> > LV Status available
> > LV # 1
> > # open 1
> > LV Size 512 MB
> > Current LE 128
> > Allocated LE 128
> > Stripes 4
> > Stripe size (KByte) 4
> > Allocation next free
> > Read ahead sectors 120
> > Block device 58:0
> >
> > # lvdisplay /dev/tripserv_vol/people
> > --- Logical volume ---
> > LV Name /dev/tripserv_vol/people
> > VG Name tripserv_vol
> > LV Write Access read/write
> > LV Status available
> > LV # 6
> > # open 0
> > LV Size 20 GB
> > Current LE 5120
> > Allocated LE 5120
> > Stripes 4
> > Stripe size (KByte) 4
> > Allocation next free
> > Read ahead sectors 120
> > Block device 58:5
> >
> > # lvdisplay /dev/tripserv_vol/pages
> > --- Logical volume ---
> > LV Name /dev/tripserv_vol/pages
> > VG Name tripserv_vol
> > LV Write Access read/write
> > LV snapshot status source of
> > /dev/tripserv_vol/pagessnap [active]
> > LV Status available
> > LV # 3
> > # open 0
> > LV Size 20 GB
> > Current LE 5120
> > Allocated LE 5120
> > Stripes 4
> > Stripe size (KByte) 4
> > Allocation next free
> > Read ahead sectors 120
> > Block device 58:2
> >
> > tripserv:/# lvdisplay /dev/tripserv_vol/pagessnap
> > --- Logical volume ---
> > LV Name /dev/tripserv_vol/pagessnap
> > VG Name tripserv_vol
> > LV Write Access read only
> > LV snapshot status active destination for /dev/tripserv_vol/pages
> > LV Status available
> > LV # 20
> > # open 0
> > LV Size 20 GB
> > Current LE 5120
> > Allocated LE 5120
> > snapshot chunk size 64 KB
> > Allocated to snapshot 0.00% [0/19.69 GB]
> > Allocated to COW-table 320 MB
> > Stripes 4
> > Stripe size (KByte) 4
> > Allocation next free
> > Read ahead sectors 120
> > Block device 58:19
> >
> > # lvdisplay /dev/tripserv_vol/docusnap
> > --- Logical volume ---
> > LV Name /dev/tripserv_vol/docusnap
> > VG Name tripserv_vol
> > LV Write Access read only
> > LV snapshot status active destination for /dev/tripserv_vol/docu
> > LV Status available
> > LV # 16
> > # open 0
> > LV Size 512 MB
> > Current LE 128
> > Allocated LE 128
> > snapshot chunk size 64 KB
> > Allocated to snapshot 0.05% [256 KB/492.19 MB]
> > Allocated to COW-table 7.81 MB
> > Stripes 4
> > Stripe size (KByte) 4
> > Allocation next free
> > Read ahead sectors 120
> > Block device 58:15
> >
> > So it all looks good!
>
> *** 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
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-lvm] Help! unable to mount lv's - can't see why!
2002-09-18 9:17 ` Robin Edgar - Tripany
@ 2002-09-19 5:05 ` Heinz J . Mauelshagen
2002-09-19 5:17 ` Robin Edgar - Tripany
0 siblings, 1 reply; 14+ messages in thread
From: Heinz J . Mauelshagen @ 2002-09-19 5:05 UTC (permalink / raw)
To: linux-lvm
On Wed, Sep 18, 2002 at 04:42:54PM +0200, Robin Edgar - Tripany wrote:
> Doing the lvdisplay -v shows that pv /dev/hde1 had bits of all of the lv's
> on it (including the docu lv, which I *can* mount).
Then it is most likely, that all filesystems will have errors.
Regards,
Heinz -- The LVM Guy --
>
> ----- Original Message -----
> From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
> To: <linux-lvm@sistina.com>
> Sent: Wednesday, September 18, 2002 3:59 PM
> Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
>
>
> > On Wed, Sep 18, 2002 at 03:56:36PM +0200, Robin Edgar - Tripany wrote:
> > > I've discovered that there is a problem with /all/ the superblocks
> except for those of the /docu lv (see below). It does lead me to another
> question though - only one of the HDs crashed: is it possible that LVM wrote
> all the superblocks on 1 HD?! If so this seems like a pretty serious bug in
<SNIP>
> > 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
> >
> >
>
>
>
> _______________________________________________
> 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
*** 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-lvm] Help! unable to mount lv's - can't see why!
2002-09-18 9:07 ` Robin Edgar - Tripany
@ 2002-09-19 5:10 ` Heinz J . Mauelshagen
0 siblings, 0 replies; 14+ messages in thread
From: Heinz J . Mauelshagen @ 2002-09-19 5:10 UTC (permalink / raw)
To: linux-lvm
On Wed, Sep 18, 2002 at 04:33:05PM +0200, Robin Edgar - Tripany wrote:
> Hi Heinz,
>
> Thanks for the help so far!
>
> How can I find out the blocksize of my lv's? So far I've tried e2fsck on the
> lv's using the mke2fs -n /dev/tripserv_vol/pages, for all blocksizes (-b
Oops.
What you wanted to run is "e2fsck -osb=N ..." to repair the existing
filesystem *not* mke2fs, which will create a new one!
As mentioned in my other email: if your logical filesystem blocksize was 4k,
your first superblock backup would have been on block 131072.
Regards,
Heinz -- The LVM Guy --
> 1024, 2048, 4096) but none of the superblocks respond to fsck. The only
> thing I can think of now is letting fsck rebuild the superblock, but I have
> to be sure of the blocksize for it to have any chance of success. Building
> the lv's, I followed the following steps:
>
> pvcreate /dev/hde
> /dev/hdf
> /dev/hdg
> /dev/hdh
>
> vgcreate tripserv_vol /dev/hde /dev/hdf /dev/hdg /dev/hdh
>
> lvcreate -i3 -I4 -L100M -nvolumename tripserv_vol
>
> mke2fs -j -Lfslabel /dev/tripserv_vol/volumename
>
> Cheers,
> Robin
>
>
> ----- Original Message -----
> From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
> To: <linux-lvm@sistina.com>
> Sent: Wednesday, September 18, 2002 3:18 PM
> Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
>
>
> > On Wed, Sep 18, 2002 at 02:07:18PM +0200, Robin Edgar - Tripany wrote:
> > > Hi,
> > >
> > > I had 4 (ide) disks in an array (and 1 vg) of which one (hde) broke. As
> I was not too sure of the stability of the system, I decided to do a dd of
> the disk byte by byte to another identical disk. After this was done (with
> loads of sector unreadable errors) I replaced the old disk with the new
> disk, rebooted the system and by all standards all seems well (see below):
> >
> > Robin,
> >
> > lots of read errors during dd likely left you with a corrupted primary
> > superblock of the filesystem.
> >
> > > Unfortunately, only the /dev/tripserv_vol/docu will mount well!
> > > /dev/tripserv_vol/pages gives the following error:
> > >
> > > # mount /dev/tripserv_vol/pages /c
> > > mount: you must specify the filesystem type
> > >
> > > # mount /dev/tripserv_vol/pages /c -t ext3
> > > mount: wrong fs type, bad option, bad superblock on
> /dev/tripserv_vol/pages,
> > > or too many mounted file systems
> > >
> > > Anyone have any ideas why it won't mount?!
> >
> > You need to figure out, if /dev/tripserv_vol/docu doesn't have *any*
> extents
> > allocated on the replaced disk. Try "lvdisplay -v /dev/tripserv_vol/docu"
> > to achive this. If it has, you'll likely find corrupted files in this one
> > too.
> >
> >
> > For the failing mount you might want to try
> >
> > "mount -r -osb=$ALTERNATE_SUPERBLOCK /dev/tripserv_vol/pages /c".
> >
> > In case you've got a logical 4k block size of the filesystem,
> > ALTERNATE_SUPERBLOCK=131072 would access the first backup copy.
> >
> > See "man mount" and look for the ext2 mount option "sb=" for more
> information.
> >
> > In case you have success with using a backup superblock this way, you need
> to
> > backup all files you can access successfully first, then recreate the
> filesystem
> > and restore. It is unlikely in the case of lots of read errors during dd,
> that
> > a fsck will help you. You'll probably end up with piles of lost+found
> entries.
> >
> > Regards,
> > Heinz -- The LVM Guy --
> >
> >
> > >
> > > Cheers,
> > > Robin Edgar
> > >
> > > #pvscan:
> > > pvscan -- reading all physical volumes (this may take a while...)
> > > pvscan -- ACTIVE PV "/dev/hdg1" of VG "tripserv_vol" [38.16 GB / 7.93
> GB free]
> > > pvscan -- ACTIVE PV "/dev/hdh1" of VG "tripserv_vol" [38.16 GB / 8.01
> GB free]
> > > pvscan -- ACTIVE PV "/dev/hde1" of VG "tripserv_vol" [55.91 GB / 0
> free]
> > > pvscan -- ACTIVE PV "/dev/hdf1" of VG "tripserv_vol" [55.91 GB / 3.37
> GB free]
> > > pvscan -- total: 4 [188.16 GB] / in use: 4 [188.16 GB] / in no VG: 0 [0]
> > >
> > > (identical output to before changing the disks around)
> > >
> > > #pvdisplay /dev/hde1
> > > --- Physical volume ---
> > > PV Name /dev/hde1
> > > VG Name tripserv_vol
> > > PV Size 55.92 GB [117266625 secs] / NOT usable 4.18 MB
> [LVM: 179 KB]
> > > PV# 1
> > > PV Status available
> > > Allocatable yes (but full)
> > > Cur LV 20
> > > PE Size (KByte) 4096
> > > Total PE 14313
> > > Free PE 0
> > > Allocated PE 14313
> > > PV UUID KCIKwa-3lvx-k7bj-27ks-hGlI-oZRo-5q7CjM
> > >
> > > (also identical)
> > >
> > > #vgck -v
> > > vgck -- locking logical volume manager
> > > vgck -- finding all volume group(s)
> > > vgck -- checking volume group name "tripserv_vol"
> > > vgck -- checking existence of volume group "tripserv_vol"
> > > vgck -- reading volume group data for "tripserv_vol" from lvmtab
> > > vgck -- checking volume group consistency of "tripserv_vol" in lvmtab
> > > vgck -- VGDA of "tripserv_vol" in lvmtab is consistent
> > > vgck -- reading volume group data for "tripserv_vol" from physical
> volume(s)
> > > vgck -- checking volume group consistency of "tripserv_vol" on physical
> volumes
> > > vgck -- VGDA of "tripserv_vol" on physical volumes is consistent
> > > vgck -- unlocking logical volume manager
> > >
> > > # vgdisplay
> > > --- Volume group ---
> > > VG Name tripserv_vol
> > > VG Access read/write
> > > VG Status available/resizable
> > > VG # 0
> > > MAX LV 255
> > > Cur LV 22
> > > Open LV 1
> > > MAX LV Size 255.99 GB
> > > Max PV 255
> > > Cur PV 4
> > > Act PV 4
> > > VG Size 188.13 GB
> > > PE Size 4 MB
> > > Total PE 48162
> > > Alloc PE / Size 43220 / 168.83 GB
> > > Free PE / Size 4942 / 19.30 GB
> > > VG UUID KDiCWx-ae2w-oDnx-Hl5O-Amhd-fIM3-y51bIX
> > >
> > > # vgscan -v
> > > vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
> > > vgscan -- creating empty "/etc/lvmtab" and "/etc/lvmtab.d"
> > > vgscan -- reading all physical volumes (this may take a while...)
> > > vgscan -- scanning for all active volume group(s) first
> > > vgscan -- found active volume group "tripserv_vol"
> > > vgscan -- reading data of volume group "tripserv_vol" from physical
> volume(s)
> > > vgscan -- inserting "tripserv_vol" into lvmtab
> > > vgscan -- backing up volume group "tripserv_vol"
> > > vgscan -- checking volume group name "tripserv_vol"
> > > vgscan -- checking volume group consistency of "tripserv_vol"
> > > vgscan -- checking existence of "/etc/lvmtab.d"
> > > vgscan -- storing volume group data of "tripserv_vol" in
> "/etc/lvmtab.d/tripserv_vol.tmp"
> > > vgscan -- storing physical volume data of "tripserv_vol" in
> "/etc/lvmtab.d/tripserv_vol.tmp"
> > > vgscan -- storing logical volume data of volume group "tripserv_vol" in
> "/etc/lvmtab.d/tripserv_vol.tmp"
> > > vgscan -- renaming "/etc/lvmtab.d/tripserv_vol.tmp" to
> "/etc/lvmtab.d/tripserv_vol"
> > > vgscan -- removing special files and directory for volume group
> "tripserv_vol"
> > > vgscan -- creating directory and group character special file for
> "tripserv_vol"
> > > vgscan -- creating block device special files for tripserv_vol
> > > vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
> > > vgscan -- WARNING: This program does not do a VGDA backup of your volume
> group
> > >
> > > #lvscan
> > > lvscan -- ACTIVE Original "/dev/tripserv_vol/docu" [512 MB] striped[4]
> > > lvscan -- ACTIVE Original "/dev/tripserv_vol/install" [10 GB]
> striped[4]
> > > lvscan -- ACTIVE Original "/dev/tripserv_vol/pages" [20 GB] striped[4]
> > > lvscan -- ACTIVE "/dev/tripserv_vol/gfx" [10 GB] striped[4]
> > > lvscan -- ACTIVE "/dev/tripserv_vol/sfx" [10 GB] striped[4]
> > > lvscan -- ACTIVE "/dev/tripserv_vol/people" [20 GB]
> striped[4]
> > > lvscan -- ACTIVE Original "/dev/tripserv_vol/dim" [2 GB] striped[4]
> > > lvscan -- ACTIVE "/dev/tripserv_vol/mp3" [20 GB] striped[4]
> > > lvscan -- ACTIVE "/dev/tripserv_vol/applications" [2 GB]
> striped[4]
> > > lvscan -- ACTIVE Original "/dev/tripserv_vol/code" [512 MB] striped[4]
> > > lvscan -- ACTIVE "/dev/tripserv_vol/dumpdir" [10 GB]
> striped[4]
> > > lvscan -- ACTIVE Original "/dev/tripserv_vol/homes" [10 GB] striped[4]
> > > lvscan -- ACTIVE Original "/dev/tripserv_vol/info" [5 GB] striped[4]
> > > lvscan -- ACTIVE "/dev/tripserv_vol/log" [252 MB] striped[3]
> > > lvscan -- ACTIVE "/dev/tripserv_vol/store" [608 MB]
> striped[4]
> > > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/docusnap" [492.19 MB] of
> /dev/tripserv_vol/docu
> > > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/installsnap" [9.84 GB] of
> /dev/tripserv_vol/install
> > > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/dimsnap" [1.97 GB] of
> /dev/tripserv_vol/dim
> > > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/codesnap" [504 MB] of
> /dev/tripserv_vol/code
> > > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/pagessnap" [19.69 GB] of
> /dev/tripserv_vol/pages
> > > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/infosnap" [4.92 GB] of
> /dev/tripserv_vol/info
> > > lvscan -- ACTIVE Snapshot "/dev/tripserv_vol/homessnap" [9.84 GB] of
> /dev/tripserv_vol/homes
> > > lvscan -- 22 logical volumes with 168.08 GB total in 1 volume group
> > > lvscan -- 22 active logical volumes
> > >
> > > # lvdisplay /dev/tripserv_vol/docu
> > > --- Logical volume ---
> > > LV Name /dev/tripserv_vol/docu
> > > VG Name tripserv_vol
> > > LV Write Access read/write
> > > LV snapshot status source of
> > > /dev/tripserv_vol/docusnap [active]
> > > LV Status available
> > > LV # 1
> > > # open 1
> > > LV Size 512 MB
> > > Current LE 128
> > > Allocated LE 128
> > > Stripes 4
> > > Stripe size (KByte) 4
> > > Allocation next free
> > > Read ahead sectors 120
> > > Block device 58:0
> > >
> > > # lvdisplay /dev/tripserv_vol/people
> > > --- Logical volume ---
> > > LV Name /dev/tripserv_vol/people
> > > VG Name tripserv_vol
> > > LV Write Access read/write
> > > LV Status available
> > > LV # 6
> > > # open 0
> > > LV Size 20 GB
> > > Current LE 5120
> > > Allocated LE 5120
> > > Stripes 4
> > > Stripe size (KByte) 4
> > > Allocation next free
> > > Read ahead sectors 120
> > > Block device 58:5
> > >
> > > # lvdisplay /dev/tripserv_vol/pages
> > > --- Logical volume ---
> > > LV Name /dev/tripserv_vol/pages
> > > VG Name tripserv_vol
> > > LV Write Access read/write
> > > LV snapshot status source of
> > > /dev/tripserv_vol/pagessnap [active]
> > > LV Status available
> > > LV # 3
> > > # open 0
> > > LV Size 20 GB
> > > Current LE 5120
> > > Allocated LE 5120
> > > Stripes 4
> > > Stripe size (KByte) 4
> > > Allocation next free
> > > Read ahead sectors 120
> > > Block device 58:2
> > >
> > > tripserv:/# lvdisplay /dev/tripserv_vol/pagessnap
> > > --- Logical volume ---
> > > LV Name /dev/tripserv_vol/pagessnap
> > > VG Name tripserv_vol
> > > LV Write Access read only
> > > LV snapshot status active destination for /dev/tripserv_vol/pages
> > > LV Status available
> > > LV # 20
> > > # open 0
> > > LV Size 20 GB
> > > Current LE 5120
> > > Allocated LE 5120
> > > snapshot chunk size 64 KB
> > > Allocated to snapshot 0.00% [0/19.69 GB]
> > > Allocated to COW-table 320 MB
> > > Stripes 4
> > > Stripe size (KByte) 4
> > > Allocation next free
> > > Read ahead sectors 120
> > > Block device 58:19
> > >
> > > # lvdisplay /dev/tripserv_vol/docusnap
> > > --- Logical volume ---
> > > LV Name /dev/tripserv_vol/docusnap
> > > VG Name tripserv_vol
> > > LV Write Access read only
> > > LV snapshot status active destination for /dev/tripserv_vol/docu
> > > LV Status available
> > > LV # 16
> > > # open 0
> > > LV Size 512 MB
> > > Current LE 128
> > > Allocated LE 128
> > > snapshot chunk size 64 KB
> > > Allocated to snapshot 0.05% [256 KB/492.19 MB]
> > > Allocated to COW-table 7.81 MB
> > > Stripes 4
> > > Stripe size (KByte) 4
> > > Allocation next free
> > > Read ahead sectors 120
> > > Block device 58:15
> > >
> > > So it all looks good!
> >
> > *** 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
> > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> >
> >
>
>
>
> _______________________________________________
> 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
*** 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-lvm] Help! unable to mount lv's - can't see why!
2002-09-19 5:05 ` Heinz J . Mauelshagen
@ 2002-09-19 5:17 ` Robin Edgar - Tripany
2002-09-19 8:55 ` Heinz J . Mauelshagen
0 siblings, 1 reply; 14+ messages in thread
From: Robin Edgar - Tripany @ 2002-09-19 5:17 UTC (permalink / raw)
To: linux-lvm
Fair enough, but I would very much like to access the files and determine
later what has errors and what doesn't - at the moment, I can only do this
with the docu lv and none of the others...
You were right, I did manage to get a whole load of lost+found entries using
fsck after the mount. The docu entry was on the physical extent though, and
seems to be working fine.
Anyway I thought I'd upgrade LVM to 1.0.5 from 1.0.1 and refit the disks to
the 'old' configuration (4 disks + 1 for backup), to do a pvmove.
Now when I do a pvscan, it finds all the disks, but also the disk I did the
dd to, as part of the vg. So I de-activated the vg, and tried to reduce the
vg /dev/hdb1, hoiwever this is not working:
# vgreduce tripserv_vol /dev/hdb1
vgreduce -- ERROR: can't reduce volume group "tripserv_vol" by used physical
volume "/dev/hdb1"
# pvscan -v
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- walking through all physical volumes found
pvscan -- ACTIVE PV "/dev/hdg1" of VG "tripserv_vol" [38.16 GB / 7.93 GB
free]
pvscan -- ACTIVE PV "/dev/hdh1" of VG "tripserv_vol" [38.16 GB / 8.01 GB
free]
pvscan -- inactive PV "/dev/hde1" of VG "tripserv_vol" [55.91 GB / 0 free]
pvscan -- ACTIVE PV "/dev/hdf1" of VG "tripserv_vol" [55.91 GB / 3.37 GB
free]
pvscan -- ACTIVE PV "/dev/hdb1" of VG "tripserv_vol" [55.91 GB / 0 free]
pvscan -- total: 5 [244.08 GB] / in use: 5 [244.08 GB] / in no VG: 0 [0]
If i vgchange -a n it will deactivate them all, but then I get:
# vgreduce tripserv_vol /dev/hdb1
vgreduce -- ERROR: volume group "tripserv_vol" is not active
After I restore the vg to it's 'old' configuration, I want to empty
/dev/hdb1 and add it to the volume group. Then doing a pvmove -i /dev/hde1
should move all the data it can find there to the rest of the vg shouldn't
it?
Thank you for all your help so far,
Robin Edgar
----- Original Message -----
From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
To: <linux-lvm@sistina.com>
Sent: Thursday, September 19, 2002 12:04 PM
Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
> On Wed, Sep 18, 2002 at 04:42:54PM +0200, Robin Edgar - Tripany wrote:
> > Doing the lvdisplay -v shows that pv /dev/hde1 had bits of all of the
lv's
> > on it (including the docu lv, which I *can* mount).
>
> Then it is most likely, that all filesystems will have errors.
>
> Regards,
> Heinz -- The LVM Guy --
>
>
> >
> > ----- Original Message -----
> > From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
> > To: <linux-lvm@sistina.com>
> > Sent: Wednesday, September 18, 2002 3:59 PM
> > Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
> >
> >
> > > On Wed, Sep 18, 2002 at 03:56:36PM +0200, Robin Edgar - Tripany wrote:
> > > > I've discovered that there is a problem with /all/ the superblocks
> > except for those of the /docu lv (see below). It does lead me to another
> > question though - only one of the HDs crashed: is it possible that LVM
wrote
> > all the superblocks on 1 HD?! If so this seems like a pretty serious bug
in
> <SNIP>
> > > 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
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > 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
>
> *** 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
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-lvm] Help! unable to mount lv's - can't see why!
2002-09-19 5:17 ` Robin Edgar - Tripany
@ 2002-09-19 8:55 ` Heinz J . Mauelshagen
2002-09-19 9:36 ` Robin Edgar - Tripany
0 siblings, 1 reply; 14+ messages in thread
From: Heinz J . Mauelshagen @ 2002-09-19 8:55 UTC (permalink / raw)
To: linux-lvm
On Thu, Sep 19, 2002 at 12:45:47PM +0200, Robin Edgar - Tripany wrote:
> Fair enough, but I would very much like to access the files and determine
> later what has errors and what doesn't - at the moment, I can only do this
> with the docu lv and none of the others...
>
> You were right, I did manage to get a whole load of lost+found entries using
> fsck after the mount. The docu entry was on the physical extent though, and
> seems to be working fine.
> Anyway I thought I'd upgrade LVM to 1.0.5 from 1.0.1 and refit the disks to
> the 'old' configuration (4 disks + 1 for backup), to do a pvmove.
> Now when I do a pvscan, it finds all the disks, but also the disk I did the
> dd to, as part of the vg. So I de-activated the vg, and tried to reduce the
> vg /dev/hdb1, hoiwever this is not working:
>
> # vgreduce tripserv_vol /dev/hdb1
> vgreduce -- ERROR: can't reduce volume group "tripserv_vol" by used physical
> volume "/dev/hdb1"
Well, LVM still has allocated extents on that PV. You can just remove
empty PVs from a VG.
>
> # pvscan -v
> pvscan -- reading all physical volumes (this may take a while...)
> pvscan -- walking through all physical volumes found
> pvscan -- ACTIVE PV "/dev/hdg1" of VG "tripserv_vol" [38.16 GB / 7.93 GB
> free]
> pvscan -- ACTIVE PV "/dev/hdh1" of VG "tripserv_vol" [38.16 GB / 8.01 GB
> free]
> pvscan -- inactive PV "/dev/hde1" of VG "tripserv_vol" [55.91 GB / 0 free]
> pvscan -- ACTIVE PV "/dev/hdf1" of VG "tripserv_vol" [55.91 GB / 3.37 GB
> free]
> pvscan -- ACTIVE PV "/dev/hdb1" of VG "tripserv_vol" [55.91 GB / 0 free]
> pvscan -- total: 5 [244.08 GB] / in use: 5 [244.08 GB] / in no VG: 0 [0]
>
> If i vgchange -a n it will deactivate them all, but then I get:
> # vgreduce tripserv_vol /dev/hdb1
> vgreduce -- ERROR: volume group "tripserv_vol" is not active
Doesn't change the situation, because the PV still has extents allocated.
A PV must be empty and the VG active in order to remove it from the VG.
>
> After I restore the vg to it's 'old' configuration, I want to empty
> /dev/hdb1 and add it to the volume group. Then doing a pvmove -i /dev/hde1
> should move all the data it can find there to the rest of the vg shouldn't
> it?
Yes, presuming that you've got enought space to fit all extents allocated
to /dev/hde1.
>
> Thank you for all your help so far,
You're welcome.
Regards,
Heinz -- The LVM Guy --
> Robin Edgar
>
> ----- Original Message -----
> From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
> To: <linux-lvm@sistina.com>
> Sent: Thursday, September 19, 2002 12:04 PM
> Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
>
>
> > On Wed, Sep 18, 2002 at 04:42:54PM +0200, Robin Edgar - Tripany wrote:
> > > Doing the lvdisplay -v shows that pv /dev/hde1 had bits of all of the
> lv's
> > > on it (including the docu lv, which I *can* mount).
> >
> > Then it is most likely, that all filesystems will have errors.
> >
> > Regards,
> > Heinz -- The LVM Guy --
> >
> >
> > >
> > > ----- Original Message -----
> > > From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
> > > To: <linux-lvm@sistina.com>
> > > Sent: Wednesday, September 18, 2002 3:59 PM
> > > Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
> > >
> > >
> > > > On Wed, Sep 18, 2002 at 03:56:36PM +0200, Robin Edgar - Tripany wrote:
> > > > > I've discovered that there is a problem with /all/ the superblocks
> > > except for those of the /docu lv (see below). It does lead me to another
> > > question though - only one of the HDs crashed: is it possible that LVM
> wrote
> > > all the superblocks on 1 HD?! If so this seems like a pretty serious bug
> in
> > <SNIP>
> > > > 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
> > > >
> > > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> >
> > *** Software bugs are stupid.
> > Nevertheless it needs not so stupid people to solve them ***
> >
> >
> > _______________________________________________
> > 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
> >
> >
>
>
>
> _______________________________________________
> 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
*** 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-lvm] Help! unable to mount lv's - can't see why!
2002-09-19 8:55 ` Heinz J . Mauelshagen
@ 2002-09-19 9:36 ` Robin Edgar - Tripany
2002-09-19 14:09 ` Heinz J . Mauelshagen
0 siblings, 1 reply; 14+ messages in thread
From: Robin Edgar - Tripany @ 2002-09-19 9:36 UTC (permalink / raw)
To: linux-lvm
Due to the dd the 2 disks should be identical - how do i get the VG to
activate the PV of choice? I can't figure out how to deactivate hdb1 and
activate hde1 or how vgchange decides it wants to use hdb1 instead of hde1!
Robin
> On Thu, Sep 19, 2002 at 12:45:47PM +0200, Robin Edgar - Tripany wrote:
> > Fair enough, but I would very much like to access the files and
determine
> > later what has errors and what doesn't - at the moment, I can only do
this
> > with the docu lv and none of the others...
> >
> > You were right, I did manage to get a whole load of lost+found entries
using
> > fsck after the mount. The docu entry was on the physical extent though,
and
> > seems to be working fine.
> > Anyway I thought I'd upgrade LVM to 1.0.5 from 1.0.1 and refit the disks
to
> > the 'old' configuration (4 disks + 1 for backup), to do a pvmove.
> > Now when I do a pvscan, it finds all the disks, but also the disk I did
the
> > dd to, as part of the vg. So I de-activated the vg, and tried to reduce
the
> > vg /dev/hdb1, hoiwever this is not working:
> >
> > # vgreduce tripserv_vol /dev/hdb1
> > vgreduce -- ERROR: can't reduce volume group "tripserv_vol" by used
physical
> > volume "/dev/hdb1"
>
> Well, LVM still has allocated extents on that PV. You can just remove
> empty PVs from a VG.
>
> >
> > # pvscan -v
> > pvscan -- reading all physical volumes (this may take a while...)
> > pvscan -- walking through all physical volumes found
> > pvscan -- ACTIVE PV "/dev/hdg1" of VG "tripserv_vol" [38.16 GB / 7.93
GB
> > free]
> > pvscan -- ACTIVE PV "/dev/hdh1" of VG "tripserv_vol" [38.16 GB / 8.01
GB
> > free]
> > pvscan -- inactive PV "/dev/hde1" of VG "tripserv_vol" [55.91 GB / 0
free]
> > pvscan -- ACTIVE PV "/dev/hdf1" of VG "tripserv_vol" [55.91 GB / 3.37
GB
> > free]
> > pvscan -- ACTIVE PV "/dev/hdb1" of VG "tripserv_vol" [55.91 GB / 0
free]
> > pvscan -- total: 5 [244.08 GB] / in use: 5 [244.08 GB] / in no VG: 0 [0]
> >
> > If i vgchange -a n it will deactivate them all, but then I get:
> > # vgreduce tripserv_vol /dev/hdb1
> > vgreduce -- ERROR: volume group "tripserv_vol" is not active
>
> Doesn't change the situation, because the PV still has extents allocated.
> A PV must be empty and the VG active in order to remove it from the VG.
>
> >
> > After I restore the vg to it's 'old' configuration, I want to empty
> > /dev/hdb1 and add it to the volume group. Then doing a pvmove -i
/dev/hde1
> > should move all the data it can find there to the rest of the vg
shouldn't
> > it?
>
> Yes, presuming that you've got enought space to fit all extents allocated
> to /dev/hde1.
>
> >
> > Thank you for all your help so far,
>
> You're welcome.
>
> Regards,
> Heinz -- The LVM Guy --
>
> > Robin Edgar
> >
> > ----- Original Message -----
> > From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
> > To: <linux-lvm@sistina.com>
> > Sent: Thursday, September 19, 2002 12:04 PM
> > Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
> >
> >
> > > On Wed, Sep 18, 2002 at 04:42:54PM +0200, Robin Edgar - Tripany wrote:
> > > > Doing the lvdisplay -v shows that pv /dev/hde1 had bits of all of
the
> > lv's
> > > > on it (including the docu lv, which I *can* mount).
> > >
> > > Then it is most likely, that all filesystems will have errors.
> > >
> > > Regards,
> > > Heinz -- The LVM Guy --
> > >
> > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
> > > > To: <linux-lvm@sistina.com>
> > > > Sent: Wednesday, September 18, 2002 3:59 PM
> > > > Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
> > > >
> > > >
> > > > > On Wed, Sep 18, 2002 at 03:56:36PM +0200, Robin Edgar - Tripany
wrote:
> > > > > > I've discovered that there is a problem with /all/ the
superblocks
> > > > except for those of the /docu lv (see below). It does lead me to
another
> > > > question though - only one of the HDs crashed: is it possible that
LVM
> > wrote
> > > > all the superblocks on 1 HD?! If so this seems like a pretty serious
bug
> > in
> > > <SNIP>
> > > > > 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
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > >
> > > *** Software bugs are stupid.
> > > Nevertheless it needs not so stupid people to solve them ***
> > >
> > >
> > > _______________________________________________
> > > 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
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > 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
>
> *** 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
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-lvm] Help! unable to mount lv's - can't see why!
2002-09-19 9:36 ` Robin Edgar - Tripany
@ 2002-09-19 14:09 ` Heinz J . Mauelshagen
2002-09-20 4:29 ` Robin Edgar - Tripany
0 siblings, 1 reply; 14+ messages in thread
From: Heinz J . Mauelshagen @ 2002-09-19 14:09 UTC (permalink / raw)
To: linux-lvm
On Thu, Sep 19, 2002 at 05:01:46PM +0200, Robin Edgar - Tripany wrote:
> Due to the dd the 2 disks should be identical - how do i get the VG to
> activate the PV of choice? I can't figure out how to deactivate hdb1 and
> activate hde1 or how vgchange decides it wants to use hdb1 instead of hde1!
Zero the first block of hdb1 (dd if=/dev/zero of=/dev/hdb1 bs=1k count=1) or
create a new physical volume on /dev/hdb1 (pvcreate -ff /dev/hdb1).
Regards,
Heinz -- The LVM Guy --
>
> Robin
>
> > On Thu, Sep 19, 2002 at 12:45:47PM +0200, Robin Edgar - Tripany wrote:
> > > Fair enough, but I would very much like to access the files and
> determine
> > > later what has errors and what doesn't - at the moment, I can only do
> this
> > > with the docu lv and none of the others...
> > >
> > > You were right, I did manage to get a whole load of lost+found entries
> using
> > > fsck after the mount. The docu entry was on the physical extent though,
> and
> > > seems to be working fine.
> > > Anyway I thought I'd upgrade LVM to 1.0.5 from 1.0.1 and refit the disks
> to
> > > the 'old' configuration (4 disks + 1 for backup), to do a pvmove.
> > > Now when I do a pvscan, it finds all the disks, but also the disk I did
> the
> > > dd to, as part of the vg. So I de-activated the vg, and tried to reduce
> the
> > > vg /dev/hdb1, hoiwever this is not working:
> > >
> > > # vgreduce tripserv_vol /dev/hdb1
> > > vgreduce -- ERROR: can't reduce volume group "tripserv_vol" by used
> physical
> > > volume "/dev/hdb1"
> >
> > Well, LVM still has allocated extents on that PV. You can just remove
> > empty PVs from a VG.
> >
> > >
> > > # pvscan -v
> > > pvscan -- reading all physical volumes (this may take a while...)
> > > pvscan -- walking through all physical volumes found
> > > pvscan -- ACTIVE PV "/dev/hdg1" of VG "tripserv_vol" [38.16 GB / 7.93
> GB
> > > free]
> > > pvscan -- ACTIVE PV "/dev/hdh1" of VG "tripserv_vol" [38.16 GB / 8.01
> GB
> > > free]
> > > pvscan -- inactive PV "/dev/hde1" of VG "tripserv_vol" [55.91 GB / 0
> free]
> > > pvscan -- ACTIVE PV "/dev/hdf1" of VG "tripserv_vol" [55.91 GB / 3.37
> GB
> > > free]
> > > pvscan -- ACTIVE PV "/dev/hdb1" of VG "tripserv_vol" [55.91 GB / 0
> free]
> > > pvscan -- total: 5 [244.08 GB] / in use: 5 [244.08 GB] / in no VG: 0 [0]
> > >
> > > If i vgchange -a n it will deactivate them all, but then I get:
> > > # vgreduce tripserv_vol /dev/hdb1
> > > vgreduce -- ERROR: volume group "tripserv_vol" is not active
> >
> > Doesn't change the situation, because the PV still has extents allocated.
> > A PV must be empty and the VG active in order to remove it from the VG.
> >
> > >
> > > After I restore the vg to it's 'old' configuration, I want to empty
> > > /dev/hdb1 and add it to the volume group. Then doing a pvmove -i
> /dev/hde1
> > > should move all the data it can find there to the rest of the vg
> shouldn't
> > > it?
> >
> > Yes, presuming that you've got enought space to fit all extents allocated
> > to /dev/hde1.
> >
> > >
> > > Thank you for all your help so far,
> >
> > You're welcome.
> >
> > Regards,
> > Heinz -- The LVM Guy --
> >
> > > Robin Edgar
> > >
> > > ----- Original Message -----
> > > From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
> > > To: <linux-lvm@sistina.com>
> > > Sent: Thursday, September 19, 2002 12:04 PM
> > > Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
> > >
> > >
> > > > On Wed, Sep 18, 2002 at 04:42:54PM +0200, Robin Edgar - Tripany wrote:
> > > > > Doing the lvdisplay -v shows that pv /dev/hde1 had bits of all of
> the
> > > lv's
> > > > > on it (including the docu lv, which I *can* mount).
> > > >
> > > > Then it is most likely, that all filesystems will have errors.
> > > >
> > > > Regards,
> > > > Heinz -- The LVM Guy --
> > > >
> > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
> > > > > To: <linux-lvm@sistina.com>
> > > > > Sent: Wednesday, September 18, 2002 3:59 PM
> > > > > Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
> > > > >
> > > > >
> > > > > > On Wed, Sep 18, 2002 at 03:56:36PM +0200, Robin Edgar - Tripany
> wrote:
> > > > > > > I've discovered that there is a problem with /all/ the
> superblocks
> > > > > except for those of the /docu lv (see below). It does lead me to
> another
> > > > > question though - only one of the HDs crashed: is it possible that
> LVM
> > > wrote
> > > > > all the superblocks on 1 HD?! If so this seems like a pretty serious
> bug
> > > in
> > > > <SNIP>
> > > > > > 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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > 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
> > > >
> > > > *** Software bugs are stupid.
> > > > Nevertheless it needs not so stupid people to solve them ***
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > > >
> > > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> >
> > *** Software bugs are stupid.
> > Nevertheless it needs not so stupid people to solve them ***
> >
> > _______________________________________________
> > 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
> >
> >
>
>
>
> _______________________________________________
> 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
*** 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-lvm] Help! unable to mount lv's - can't see why!
2002-09-19 14:09 ` Heinz J . Mauelshagen
@ 2002-09-20 4:29 ` Robin Edgar - Tripany
2002-09-20 4:51 ` Heinz J . Mauelshagen
0 siblings, 1 reply; 14+ messages in thread
From: Robin Edgar - Tripany @ 2002-09-20 4:29 UTC (permalink / raw)
To: linux-lvm
Thanks! I got hde1 back on the vg and I can access it now - I'm surprised
that the dd'ed hdb1 couldn't mount the lv's!
I'm now wondering why the dd copy wouldn't work, because in principle it
should have copied all the faulty blocks exactly (I did it @ 1k block
size)...
Last question (hopefully :)):
does pvmove delete all the files after it has copyed all the files or is it
copy a file, delete a file - I'm worried about the PC hanging during the
operation..
Robin
----- Original Message -----
From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
To: <linux-lvm@sistina.com>
Sent: Thursday, September 19, 2002 9:07 PM
Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
> On Thu, Sep 19, 2002 at 05:01:46PM +0200, Robin Edgar - Tripany wrote:
> > Due to the dd the 2 disks should be identical - how do i get the VG to
> > activate the PV of choice? I can't figure out how to deactivate hdb1 and
> > activate hde1 or how vgchange decides it wants to use hdb1 instead of
hde1!
>
> Zero the first block of hdb1 (dd if=/dev/zero of=/dev/hdb1 bs=1k count=1)
or
> create a new physical volume on /dev/hdb1 (pvcreate -ff /dev/hdb1).
>
> Regards,
> Heinz -- The LVM Guy --
>
> >
> > Robin
> >
> > > On Thu, Sep 19, 2002 at 12:45:47PM +0200, Robin Edgar - Tripany wrote:
> > > > Fair enough, but I would very much like to access the files and
> > determine
> > > > later what has errors and what doesn't - at the moment, I can only
do
> > this
> > > > with the docu lv and none of the others...
> > > >
> > > > You were right, I did manage to get a whole load of lost+found
entries
> > using
> > > > fsck after the mount. The docu entry was on the physical extent
though,
> > and
> > > > seems to be working fine.
> > > > Anyway I thought I'd upgrade LVM to 1.0.5 from 1.0.1 and refit the
disks
> > to
> > > > the 'old' configuration (4 disks + 1 for backup), to do a pvmove.
> > > > Now when I do a pvscan, it finds all the disks, but also the disk I
did
> > the
> > > > dd to, as part of the vg. So I de-activated the vg, and tried to
reduce
> > the
> > > > vg /dev/hdb1, hoiwever this is not working:
> > > >
> > > > # vgreduce tripserv_vol /dev/hdb1
> > > > vgreduce -- ERROR: can't reduce volume group "tripserv_vol" by used
> > physical
> > > > volume "/dev/hdb1"
> > >
> > > Well, LVM still has allocated extents on that PV. You can just remove
> > > empty PVs from a VG.
> > >
> > > >
> > > > # pvscan -v
> > > > pvscan -- reading all physical volumes (this may take a while...)
> > > > pvscan -- walking through all physical volumes found
> > > > pvscan -- ACTIVE PV "/dev/hdg1" of VG "tripserv_vol" [38.16 GB /
7.93
> > GB
> > > > free]
> > > > pvscan -- ACTIVE PV "/dev/hdh1" of VG "tripserv_vol" [38.16 GB /
8.01
> > GB
> > > > free]
> > > > pvscan -- inactive PV "/dev/hde1" of VG "tripserv_vol" [55.91 GB / 0
> > free]
> > > > pvscan -- ACTIVE PV "/dev/hdf1" of VG "tripserv_vol" [55.91 GB /
3.37
> > GB
> > > > free]
> > > > pvscan -- ACTIVE PV "/dev/hdb1" of VG "tripserv_vol" [55.91 GB / 0
> > free]
> > > > pvscan -- total: 5 [244.08 GB] / in use: 5 [244.08 GB] / in no VG: 0
[0]
> > > >
> > > > If i vgchange -a n it will deactivate them all, but then I get:
> > > > # vgreduce tripserv_vol /dev/hdb1
> > > > vgreduce -- ERROR: volume group "tripserv_vol" is not active
> > >
> > > Doesn't change the situation, because the PV still has extents
allocated.
> > > A PV must be empty and the VG active in order to remove it from the
VG.
> > >
> > > >
> > > > After I restore the vg to it's 'old' configuration, I want to empty
> > > > /dev/hdb1 and add it to the volume group. Then doing a pvmove -i
> > /dev/hde1
> > > > should move all the data it can find there to the rest of the vg
> > shouldn't
> > > > it?
> > >
> > > Yes, presuming that you've got enought space to fit all extents
allocated
> > > to /dev/hde1.
> > >
> > > >
> > > > Thank you for all your help so far,
> > >
> > > You're welcome.
> > >
> > > Regards,
> > > Heinz -- The LVM Guy --
> > >
> > > > Robin Edgar
> > > >
> > > > ----- Original Message -----
> > > > From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
> > > > To: <linux-lvm@sistina.com>
> > > > Sent: Thursday, September 19, 2002 12:04 PM
> > > > Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
> > > >
> > > >
> > > > > On Wed, Sep 18, 2002 at 04:42:54PM +0200, Robin Edgar - Tripany
wrote:
> > > > > > Doing the lvdisplay -v shows that pv /dev/hde1 had bits of all
of
> > the
> > > > lv's
> > > > > > on it (including the docu lv, which I *can* mount).
> > > > >
> > > > > Then it is most likely, that all filesystems will have errors.
> > > > >
> > > > > Regards,
> > > > > Heinz -- The LVM Guy --
> > > > >
> > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
> > > > > > To: <linux-lvm@sistina.com>
> > > > > > Sent: Wednesday, September 18, 2002 3:59 PM
> > > > > > Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see
why!
> > > > > >
> > > > > >
> > > > > > > On Wed, Sep 18, 2002 at 03:56:36PM +0200, Robin Edgar -
Tripany
> > wrote:
> > > > > > > > I've discovered that there is a problem with /all/ the
> > superblocks
> > > > > > except for those of the /docu lv (see below). It does lead me to
> > another
> > > > > > question though - only one of the HDs crashed: is it possible
that
> > LVM
> > > > wrote
> > > > > > all the superblocks on 1 HD?! If so this seems like a pretty
serious
> > bug
> > > > in
> > > > > <SNIP>
> > > > > > > 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
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
> > > > >
> > > > > *** Software bugs are stupid.
> > > > > Nevertheless it needs not so stupid people to solve them ***
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > 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
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > >
> > > *** Software bugs are stupid.
> > > Nevertheless it needs not so stupid people to solve them ***
> > >
> > > _______________________________________________
> > > 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
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > 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
>
> *** 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
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-lvm] Help! unable to mount lv's - can't see why!
2002-09-20 4:29 ` Robin Edgar - Tripany
@ 2002-09-20 4:51 ` Heinz J . Mauelshagen
0 siblings, 0 replies; 14+ messages in thread
From: Heinz J . Mauelshagen @ 2002-09-20 4:51 UTC (permalink / raw)
To: linux-lvm
On Fri, Sep 20, 2002 at 11:53:55AM +0200, Robin Edgar - Tripany wrote:
> Thanks! I got hde1 back on the vg and I can access it now - I'm surprised
> that the dd'ed hdb1 couldn't mount the lv's!
> I'm now wondering why the dd copy wouldn't work, because in principle it
> should have copied all the faulty blocks exactly (I did it @ 1k block
> size)...
> Last question (hopefully :)):
> does pvmove delete all the files after it has copyed all the files or is it
> copy a file, delete a file - I'm worried about the PC hanging during the
> operation..
It copies LV extents which are typically 4MB in size rather than files.
That happens at the block device, not at the file system level.
The worst thing which can extremely seldom happen (for eg. because your machine
has a power outage) is, that a metadata restore is needed.
Don't worry, that's *very* seldom :-)
Regards,
Heinz -- The LVM Guy --
>
> Robin
>
> ----- Original Message -----
> From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
> To: <linux-lvm@sistina.com>
> Sent: Thursday, September 19, 2002 9:07 PM
> Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
>
>
> > On Thu, Sep 19, 2002 at 05:01:46PM +0200, Robin Edgar - Tripany wrote:
> > > Due to the dd the 2 disks should be identical - how do i get the VG to
> > > activate the PV of choice? I can't figure out how to deactivate hdb1 and
> > > activate hde1 or how vgchange decides it wants to use hdb1 instead of
> hde1!
> >
> > Zero the first block of hdb1 (dd if=/dev/zero of=/dev/hdb1 bs=1k count=1)
> or
> > create a new physical volume on /dev/hdb1 (pvcreate -ff /dev/hdb1).
> >
> > Regards,
> > Heinz -- The LVM Guy --
> >
> > >
> > > Robin
> > >
> > > > On Thu, Sep 19, 2002 at 12:45:47PM +0200, Robin Edgar - Tripany wrote:
> > > > > Fair enough, but I would very much like to access the files and
> > > determine
> > > > > later what has errors and what doesn't - at the moment, I can only
> do
> > > this
> > > > > with the docu lv and none of the others...
> > > > >
> > > > > You were right, I did manage to get a whole load of lost+found
> entries
> > > using
> > > > > fsck after the mount. The docu entry was on the physical extent
> though,
> > > and
> > > > > seems to be working fine.
> > > > > Anyway I thought I'd upgrade LVM to 1.0.5 from 1.0.1 and refit the
> disks
> > > to
> > > > > the 'old' configuration (4 disks + 1 for backup), to do a pvmove.
> > > > > Now when I do a pvscan, it finds all the disks, but also the disk I
> did
> > > the
> > > > > dd to, as part of the vg. So I de-activated the vg, and tried to
> reduce
> > > the
> > > > > vg /dev/hdb1, hoiwever this is not working:
> > > > >
> > > > > # vgreduce tripserv_vol /dev/hdb1
> > > > > vgreduce -- ERROR: can't reduce volume group "tripserv_vol" by used
> > > physical
> > > > > volume "/dev/hdb1"
> > > >
> > > > Well, LVM still has allocated extents on that PV. You can just remove
> > > > empty PVs from a VG.
> > > >
> > > > >
> > > > > # pvscan -v
> > > > > pvscan -- reading all physical volumes (this may take a while...)
> > > > > pvscan -- walking through all physical volumes found
> > > > > pvscan -- ACTIVE PV "/dev/hdg1" of VG "tripserv_vol" [38.16 GB /
> 7.93
> > > GB
> > > > > free]
> > > > > pvscan -- ACTIVE PV "/dev/hdh1" of VG "tripserv_vol" [38.16 GB /
> 8.01
> > > GB
> > > > > free]
> > > > > pvscan -- inactive PV "/dev/hde1" of VG "tripserv_vol" [55.91 GB / 0
> > > free]
> > > > > pvscan -- ACTIVE PV "/dev/hdf1" of VG "tripserv_vol" [55.91 GB /
> 3.37
> > > GB
> > > > > free]
> > > > > pvscan -- ACTIVE PV "/dev/hdb1" of VG "tripserv_vol" [55.91 GB / 0
> > > free]
> > > > > pvscan -- total: 5 [244.08 GB] / in use: 5 [244.08 GB] / in no VG: 0
> [0]
> > > > >
> > > > > If i vgchange -a n it will deactivate them all, but then I get:
> > > > > # vgreduce tripserv_vol /dev/hdb1
> > > > > vgreduce -- ERROR: volume group "tripserv_vol" is not active
> > > >
> > > > Doesn't change the situation, because the PV still has extents
> allocated.
> > > > A PV must be empty and the VG active in order to remove it from the
> VG.
> > > >
> > > > >
> > > > > After I restore the vg to it's 'old' configuration, I want to empty
> > > > > /dev/hdb1 and add it to the volume group. Then doing a pvmove -i
> > > /dev/hde1
> > > > > should move all the data it can find there to the rest of the vg
> > > shouldn't
> > > > > it?
> > > >
> > > > Yes, presuming that you've got enought space to fit all extents
> allocated
> > > > to /dev/hde1.
> > > >
> > > > >
> > > > > Thank you for all your help so far,
> > > >
> > > > You're welcome.
> > > >
> > > > Regards,
> > > > Heinz -- The LVM Guy --
> > > >
> > > > > Robin Edgar
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
> > > > > To: <linux-lvm@sistina.com>
> > > > > Sent: Thursday, September 19, 2002 12:04 PM
> > > > > Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see why!
> > > > >
> > > > >
> > > > > > On Wed, Sep 18, 2002 at 04:42:54PM +0200, Robin Edgar - Tripany
> wrote:
> > > > > > > Doing the lvdisplay -v shows that pv /dev/hde1 had bits of all
> of
> > > the
> > > > > lv's
> > > > > > > on it (including the docu lv, which I *can* mount).
> > > > > >
> > > > > > Then it is most likely, that all filesystems will have errors.
> > > > > >
> > > > > > Regards,
> > > > > > Heinz -- The LVM Guy --
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
> > > > > > > To: <linux-lvm@sistina.com>
> > > > > > > Sent: Wednesday, September 18, 2002 3:59 PM
> > > > > > > Subject: Re: [linux-lvm] Help! unable to mount lv's - can't see
> why!
> > > > > > >
> > > > > > >
> > > > > > > > On Wed, Sep 18, 2002 at 03:56:36PM +0200, Robin Edgar -
> Tripany
> > > wrote:
> > > > > > > > > I've discovered that there is a problem with /all/ the
> > > superblocks
> > > > > > > except for those of the /docu lv (see below). It does lead me to
> > > another
> > > > > > > question though - only one of the HDs crashed: is it possible
> that
> > > LVM
> > > > > wrote
> > > > > > > all the superblocks on 1 HD?! If so this seems like a pretty
> serious
> > > bug
> > > > > in
> > > > > > <SNIP>
> > > > > > > > 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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > 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
> > > > > >
> > > > > > *** Software bugs are stupid.
> > > > > > Nevertheless it needs not so stupid people to solve them ***
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > 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
> > > >
> > > > *** Software bugs are stupid.
> > > > Nevertheless it needs not so stupid people to solve them ***
> > > >
> > > > _______________________________________________
> > > > 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
> > > >
> > > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> >
> > _______________________________________________
> > 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
> >
> >
>
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
*** 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2002-09-20 4:51 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-09-18 6:37 [linux-lvm] Help! unable to mount lv's - can't see why! Robin Edgar - Tripany
2002-09-18 8:20 ` Heinz J . Mauelshagen
2002-09-18 9:07 ` Robin Edgar - Tripany
2002-09-19 5:10 ` Heinz J . Mauelshagen
2002-09-18 8:27 ` Robin Edgar - Tripany
2002-09-18 9:01 ` Heinz J . Mauelshagen
2002-09-18 9:17 ` Robin Edgar - Tripany
2002-09-19 5:05 ` Heinz J . Mauelshagen
2002-09-19 5:17 ` Robin Edgar - Tripany
2002-09-19 8:55 ` Heinz J . Mauelshagen
2002-09-19 9:36 ` Robin Edgar - Tripany
2002-09-19 14:09 ` Heinz J . Mauelshagen
2002-09-20 4:29 ` Robin Edgar - Tripany
2002-09-20 4:51 ` Heinz J . Mauelshagen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.