[linux-lvm] Remount a LVM Vol after a system crash

[linux-lvm] Remount a LVM Vol after a system crash

[Christoph Berger]

[-- Attachment #1: Type: text/plain, Size: 2760 bytes --]

Hello,
A few days ago my system crashes and i’ve used LVM v 0.8 with one volume
group(server), two physical volumes(hda6, hdb6) and one logical
volume(dev/server/ftp)
Now i’ve installed Suse 7.2 with LVM v 0.9 Beta7, but i can’t mount the
logical volume.
The error message is:
# mount /dev/server/ftp /mnt
mount: wrong fs type, bad option, bad superblock on /dev/server/ftp,
       or too many mounted file systems
 
I get the following outputs from my system:
 
# vgscan
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- found active volume group "server"
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
vgscan -- WARNING: This program does not do a VGDA backup of your volume
group
 
# pvscan
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE   PV "/dev/hda6" of VG "server" [37.78 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/hdb5" of VG "server" [41.92 GB / 0 free]
pvscan -- total: 2 [79.71 GB] / in use: 2 [79.71 GB] / in no VG: 0 [0]
 
# pvdisplay /dev/hda6
--- Physical volume ---
PV Name               /dev/hda6
VG Name               server
PV Size               37.78 GB / NOT usable 3.75 MB [LVM: 267 KB]
PV#                   1
PV Status             available
Allocatable           yes (but full)
Cur LV                1
PE Size (KByte)       4096
Total PE              9671
Free PE               0
Allocated PE          9671
PV UUID               /dev/h-da6
 
# pvdisplay /dev/hdb5
--- Physical volume ---
PV Name               /dev/hdb5
VG Name               server
PV Size               41.93 GB / NOT usable 3.45 MB [LVM: 271 KB]
PV#                   2
PV Status             available
Allocatable           yes (but full)
Cur LV                1
PE Size (KByte)       4096
Total PE              10732
Free PE               0
Allocated PE          10732
PV UUID               /dev/h-db5
 
# vgchange -ay
vgchange -- volume group "server" already active
 
# lvchange -ay /dev/server/ftp
lvchange -- logical volume "/dev/server/ftp" is already active
lvchange -- availability of logical volume "/dev/server/ftp" doesn't
have to be changed
lvchange -- logical volume "/dev/server/ftp" didn't have to be changed
 
 
I’ve tried to follow the instructions of the mailing list article, i’ve
found at http://www.geocrawler.com/archives/3/3500/2001/4/0/5655568/
But it doesn’t work, After vgchange –ay I get an error message, too,
like
 
vgcfgrestore -- ERROR: different structure size stored in
"/etc/lvmconf/export.conf"
than expected in file vg_cfgrestore.c [line 
> 120]
> vgcfgrestore -- ERROR "vg_cfgrestore(): read" restoring volume group
"export"
 
I hope you can help me,
Thanks 
Christoph 

[-- Attachment #2: Type: text/html, Size: 18652 bytes --]

Re: [linux-lvm] Remount a LVM Vol after a system crash

[Heinz J . Mauelshagen]

Christoph,

I assume that you are suffering from a PE missalignent flaw which was
in 0.9 Beta 7.

Please update to the recent LVM version available at www.sistina.com.
Follow the information in INSTALL and PATCHES/README to get your SuSE system
updated. You need to have the kernel source package and the gcc packages
installed in order to be able to do this.

Regards,
Heinz    -- The LVM Guy --


On Tue, Oct 16, 2001 at 06:19:38PM +0200, Christoph Berger wrote:
> Hello,
> A few days ago my system crashes and i’ve used LVM v 0.8 with one volume
> group(server), two physical volumes(hda6, hdb6) and one logical
> volume(dev/server/ftp)
> Now i’ve installed Suse 7.2 with LVM v 0.9 Beta7, but i can’t mount the
> logical volume.
> The error message is:
> # mount /dev/server/ftp /mnt
> mount: wrong fs type, bad option, bad superblock on /dev/server/ftp,
>        or too many mounted file systems
>  
> I get the following outputs from my system:
>  
> # vgscan
> vgscan -- reading all physical volumes (this may take a while...)
> vgscan -- found active volume group "server"
> vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
> vgscan -- WARNING: This program does not do a VGDA backup of your volume
> group
>  
> # pvscan
> pvscan -- reading all physical volumes (this may take a while...)
> pvscan -- ACTIVE   PV "/dev/hda6" of VG "server" [37.78 GB / 0 free]
> pvscan -- ACTIVE   PV "/dev/hdb5" of VG "server" [41.92 GB / 0 free]
> pvscan -- total: 2 [79.71 GB] / in use: 2 [79.71 GB] / in no VG: 0 [0]
>  
> # pvdisplay /dev/hda6
> --- Physical volume ---
> PV Name               /dev/hda6
> VG Name               server
> PV Size               37.78 GB / NOT usable 3.75 MB [LVM: 267 KB]
> PV#                   1
> PV Status             available
> Allocatable           yes (but full)
> Cur LV                1
> PE Size (KByte)       4096
> Total PE              9671
> Free PE               0
> Allocated PE          9671
> PV UUID               /dev/h-da6
>  
> # pvdisplay /dev/hdb5
> --- Physical volume ---
> PV Name               /dev/hdb5
> VG Name               server
> PV Size               41.93 GB / NOT usable 3.45 MB [LVM: 271 KB]
> PV#                   2
> PV Status             available
> Allocatable           yes (but full)
> Cur LV                1
> PE Size (KByte)       4096
> Total PE              10732
> Free PE               0
> Allocated PE          10732
> PV UUID               /dev/h-db5
>  
> # vgchange -ay
> vgchange -- volume group "server" already active
>  
> # lvchange -ay /dev/server/ftp
> lvchange -- logical volume "/dev/server/ftp" is already active
> lvchange -- availability of logical volume "/dev/server/ftp" doesn't
> have to be changed
> lvchange -- logical volume "/dev/server/ftp" didn't have to be changed
>  
>  
> I’ve tried to follow the instructions of the mailing list article, i’ve
> found at http://www.geocrawler.com/archives/3/3500/2001/4/0/5655568/
> But it doesn’t work, After vgchange –ay I get an error message, too,
> like
>  
> vgcfgrestore -- ERROR: different structure size stored in
> "/etc/lvmconf/export.conf"
> than expected in file vg_cfgrestore.c [line 
> > 120]
> > vgcfgrestore -- ERROR "vg_cfgrestore(): read" restoring volume group
> "export"
>  
> I hope you can help me,
> Thanks 
> Christoph 

*** 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] read_intr errors

[Erick Calder]

hi everyone, I've read a number of dialogues on the archives concerning the
errors below which I'm getting but have not found any answers:

I'm running RedHat 7.0 (2.4.9 kernel + LVM 1.0.1rc1) on a little PIII box
and I'm using the ide controllers built into the motherboard (drivers built
into the kernel - not modules).  I have CONFIG_IDEDISK_MULTI_MODE set to y
in the .config for the kernel.  The drive is an IBM-DTLA-307030 (as reported
by /proc/ide) and is brand new.

here are the errors:

Oct 17 02:00:34 beowulf kernel: hdc: read_intr: error=0x04 {
DriveStatusError }
Oct 17 02:00:34 beowulf kernel: hdc: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Oct 17 02:00:34 beowulf kernel: hdc: read_intr: error=0x04 {
DriveStatusError }
Oct 17 02:00:34 beowulf kernel: ide1: reset: success

I've been moving data in and out of the drive and everything seems ok but I
get lots of the above errors which leaves me with a queasy feeling...
anyone know what the deal is with this?

1k thx - e

Re: [linux-lvm] read_intr errors

[Patrick Caulfield]

On Wed, Oct 17, 2001 at 02:27:21AM -0700, Erick Calder wrote:
> hi everyone, I've read a number of dialogues on the archives concerning the
> errors below which I'm getting but have not found any answers:
> 
> I'm running RedHat 7.0 (2.4.9 kernel + LVM 1.0.1rc1) on a little PIII box
> and I'm using the ide controllers built into the motherboard (drivers built
> into the kernel - not modules).  I have CONFIG_IDEDISK_MULTI_MODE set to y
> in the .config for the kernel.  The drive is an IBM-DTLA-307030 (as reported
> by /proc/ide) and is brand new.
> 
> here are the errors:
> 
> Oct 17 02:00:34 beowulf kernel: hdc: read_intr: error=0x04 {
> DriveStatusError }
> Oct 17 02:00:34 beowulf kernel: hdc: read_intr: status=0x59 { DriveReady
> SeekComplete DataRequest Error }
> Oct 17 02:00:34 beowulf kernel: hdc: read_intr: error=0x04 {
> DriveStatusError }
> Oct 17 02:00:34 beowulf kernel: ide1: reset: success
> 
> I've been moving data in and out of the drive and everything seems ok but I
> get lots of the above errors which leaves me with a queasy feeling...
> anyone know what the deal is with this?

I'm afraid they look a lot like hardware errors to me. It might just be that it
doesn't like MULTI_MODE though. I'm not an IDE expert.

patrick

RE: [linux-lvm] read_intr errors

[Erick Calder]

Patrick,

> I'm afraid they look a lot like hardware errors to me. It might just be
that it
> doesn't like MULTI_MODE though. I'm not an IDE expert.

I turned MULTI_MODE on at a suggestion aimed to fix these very problems...
they certainly are hardware errors but as we know anecdotally from other
postings, the hardware can be perfectly ok and the errors still persist.  as
my drive is brand new and I had no such errors before installing a PV on it,
it seems reasonable to think it's not the drive.

is my data at risk of corruption?  I've slowly been checking the integrity
of files but I'm concerned about backing up bad data!

-----Original Message-----
From:	linux-lvm-admin@sistina.com [mailto:linux-lvm-admin@sistina.com] On
Behalf Of Patrick Caulfield
Sent:	Wednesday, October 17, 2001 7:30 AM
To:	linux-lvm@sistina.com
Subject:	Re: [linux-lvm] read_intr errors

On Wed, Oct 17, 2001 at 02:27:21AM -0700, Erick Calder wrote:
> hi everyone, I've read a number of dialogues on the archives concerning
the
> errors below which I'm getting but have not found any answers:
>
> I'm running RedHat 7.0 (2.4.9 kernel + LVM 1.0.1rc1) on a little PIII box
> and I'm using the ide controllers built into the motherboard (drivers
built
> into the kernel - not modules).  I have CONFIG_IDEDISK_MULTI_MODE set to y
> in the .config for the kernel.  The drive is an IBM-DTLA-307030 (as
reported
> by /proc/ide) and is brand new.
>
> here are the errors:
>
> Oct 17 02:00:34 beowulf kernel: hdc: read_intr: error=0x04 {
> DriveStatusError }
> Oct 17 02:00:34 beowulf kernel: hdc: read_intr: status=0x59 { DriveReady
> SeekComplete DataRequest Error }
> Oct 17 02:00:34 beowulf kernel: hdc: read_intr: error=0x04 {
> DriveStatusError }
> Oct 17 02:00:34 beowulf kernel: ide1: reset: success
>
> I've been moving data in and out of the drive and everything seems ok but
I
> get lots of the above errors which leaves me with a queasy feeling...
> anyone know what the deal is with this?

I'm afraid they look a lot like hardware errors to me. It might just be that
it
doesn't like MULTI_MODE though. I'm not an IDE expert.

patrick


_______________________________________________
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

Re: [linux-lvm] read_intr errors

[Patrick Caulfield]

On Wed, Oct 17, 2001 at 01:08:30PM -0700, Erick Calder wrote:
> Patrick,
> 
> > I'm afraid they look a lot like hardware errors to me. It might just be
> that it
> > doesn't like MULTI_MODE though. I'm not an IDE expert.
> 
> I turned MULTI_MODE on at a suggestion aimed to fix these very problems...
> they certainly are hardware errors but as we know anecdotally from other
> postings, the hardware can be perfectly ok and the errors still persist.  as
> my drive is brand new and I had no such errors before installing a PV on it,
> it seems reasonable to think it's not the drive.
> 
> is my data at risk of corruption?  I've slowly been checking the integrity
> of files but I'm concerned about backing up bad data!

Just because the drive is new doesn't mean it's not bust(!). 

I would do as someone suggested and run badblocks on the disk and if it gives
errors then take it back. If not then it may be related to some reports we saw
a while ago about LVM reading past the end of a SCSI disk - you can easily
verify this by making a filesystem on the PV rather that using LVM (If you're
happy with your backups that is...).

patrick

RE: [linux-lvm] read_intr errors

[Erick Calder]

Patrick,

sorry for the delay, it takes 12 hours to back up this guy and another 12 to
verify... and I had problems so I had to do it several times.

so if I get you correctly, I should be able to do badblock check (instead of
a mke2fs with -c option as has been suggested) and get an evaluation for
whether this drive has problems equally well, no?

here's what I did:

# df -k
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda1             38456308   2670876  33831932   8% /
/dev/LVM/mp3z         29540436  13308716  14731152  48% /var/mp3z

# umount /dev/LVM/mp3z
# vgchange -a n
vgchange -- volume group "LVM" successfully deactivated

root@beowulf:/root # badblocks -s /dev/hdc 29540436
Checking for bad blocks (read-only test): done

as you can see, no errors.  Now, having said that, I've come to realise that
the errors I get happen when accessing my tape drive (which is scsi) - at
least I think that's what's happening... weird.  do you then think this is
related to the problems others have had? and if so, was there a fix?

- e r i c k

-----Original Message-----
From:	linux-lvm-admin@sistina.com [mailto:linux-lvm-admin@sistina.com] On
Behalf Of Patrick Caulfield
Sent:	Thursday, October 18, 2001 12:42 AM
To:	linux-lvm@sistina.com
Subject:	Re: [linux-lvm] read_intr errors

On Wed, Oct 17, 2001 at 01:08:30PM -0700, Erick Calder wrote:
> Patrick,
>
> > I'm afraid they look a lot like hardware errors to me. It might just be
> that it
> > doesn't like MULTI_MODE though. I'm not an IDE expert.
>
> I turned MULTI_MODE on at a suggestion aimed to fix these very problems...
> they certainly are hardware errors but as we know anecdotally from other
> postings, the hardware can be perfectly ok and the errors still persist.
as
> my drive is brand new and I had no such errors before installing a PV on
it,
> it seems reasonable to think it's not the drive.
>
> is my data at risk of corruption?  I've slowly been checking the integrity
> of files but I'm concerned about backing up bad data!

Just because the drive is new doesn't mean it's not bust(!).

I would do as someone suggested and run badblocks on the disk and if it
gives
errors then take it back. If not then it may be related to some reports we
saw
a while ago about LVM reading past the end of a SCSI disk - you can easily
verify this by making a filesystem on the PV rather that using LVM (If
you're
happy with your backups that is...).

patrick


_______________________________________________
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

Re: [linux-lvm] read_intr errors

[Patrick Caulfield]

On Tue, Oct 23, 2001 at 09:18:44PM -0700, Erick Calder wrote:
> Patrick,
> 
> sorry for the delay, it takes 12 hours to back up this guy and another 12 to
> verify... and I had problems so I had to do it several times.
> 
> so if I get you correctly, I should be able to do badblock check (instead of
> a mke2fs with -c option as has been suggested) and get an evaluation for
> whether this drive has problems equally well, no?
> 
> here's what I did:
> 
> # df -k
> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/hda1             38456308   2670876  33831932   8% /
> /dev/LVM/mp3z         29540436  13308716  14731152  48% /var/mp3z
> 
> # umount /dev/LVM/mp3z
> # vgchange -a n
> vgchange -- volume group "LVM" successfully deactivated
> 
> root@beowulf:/root # badblocks -s /dev/hdc 29540436
> Checking for bad blocks (read-only test): done

Well that looks OK
 
> as you can see, no errors.  Now, having said that, I've come to realise that
> the errors I get happen when accessing my tape drive (which is scsi) - at
> least I think that's what's happening... weird.  do you then think this is
> related to the problems others have had? and if so, was there a fix?

The thread about SCSI errors just stopped so I don't know what happened there.
There was some thought that maybe LVM was trying to access beyond the end of the
disk so you could check to see if the LV is using all the space on /dev/hdc and
back it off a little so see if that helps. It may also be worth upgrading to
LVM 1.0.1rc4.

If it is the SCSI tape drive interfering then that's really odd because SCSI
shouldnot interfere with IDE unles you have some interrupt clashes or perhaps
bad cabling causing signal noise.

Not very conclusive I'm afraid, but I did say I wasn't an IDE expert!

patrick

RE: [linux-lvm] read_intr errors

[Erick Calder]

Patrick,

looking over the man page on lvreduce it states:

> lvreduce allows you to reduce the size of a  logical  volume.
> Be  careful  when reducing a logical volume's size,
> because data in the reduced part is lost!!!

the above warning is not conclusive as to whether data loss occurs only when
the LV is full i.e. it has no choice but to lose data, of if data loss may
occur regardless i.e. there's no smarts in lvreduce to move data around...

can you clarify this point and perhaps reword the above for a next release
of that man page?

anyhow, I understand what you're suggesting... however it's not clear to me
what "a little" means... would 1K do? 1M?

here's what I've got:

# lvdisplay /dev/LVM/mp3z
--- Logical volume ---
LV Name                /dev/LVM/mp3z
VG Name                LVM
LV Write Access        read/write
LV Status              available
LV #                   1
# open                 1
LV Size                28.62 GB
Current LE             7327
Allocated LE           7327
Allocation             next free
Read ahead sectors     120
Block device           58:0

# pvdisplay /dev/hdc
--- Physical volume ---
PV Name               /dev/hdc
VG Name               LVM
PV Size               28.63 GB / NOT usable 6.69 MB [LVM: 152.00 KB]
PV#                   1
PV Status             NOT available
Allocatable           yes (but full)
Cur LV                1
PE Size (KByte)       4096
Total PE              7327
Free PE               0
Allocated PE          7327
PV UUID               vY9apM-RXf6-DtiS-m4LI-u7qT-iNjm-9SYnMz

with the above, would I do:

# lvreduce -l -1 /dev/LVM/mp3z

to test this theory?

1k thx - e

-----Original Message-----
From:	linux-lvm-admin@sistina.com [mailto:linux-lvm-admin@sistina.com] On
Behalf Of Patrick Caulfield
Sent:	Wednesday, October 24, 2001 2:14 AM
To:	linux-lvm@sistina.com
Subject:	Re: [linux-lvm] read_intr errors

On Tue, Oct 23, 2001 at 09:18:44PM -0700, Erick Calder wrote:
> Patrick,
>
> sorry for the delay, it takes 12 hours to back up this guy and another 12
to
> verify... and I had problems so I had to do it several times.
>
> so if I get you correctly, I should be able to do badblock check (instead
of
> a mke2fs with -c option as has been suggested) and get an evaluation for
> whether this drive has problems equally well, no?
>
> here's what I did:
>
> # df -k
> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/hda1             38456308   2670876  33831932   8% /
> /dev/LVM/mp3z         29540436  13308716  14731152  48% /var/mp3z
>
> # umount /dev/LVM/mp3z
> # vgchange -a n
> vgchange -- volume group "LVM" successfully deactivated
>
> root@beowulf:/root # badblocks -s /dev/hdc 29540436
> Checking for bad blocks (read-only test): done

Well that looks OK

> as you can see, no errors.  Now, having said that, I've come to realise
that
> the errors I get happen when accessing my tape drive (which is scsi) - at
> least I think that's what's happening... weird.  do you then think this is
> related to the problems others have had? and if so, was there a fix?

The thread about SCSI errors just stopped so I don't know what happened
there.
There was some thought that maybe LVM was trying to access beyond the end of
the
disk so you could check to see if the LV is using all the space on /dev/hdc
and
back it off a little so see if that helps. It may also be worth upgrading to
LVM 1.0.1rc4.

If it is the SCSI tape drive interfering then that's really odd because SCSI
shouldnot interfere with IDE unles you have some interrupt clashes or
perhaps
bad cabling causing signal noise.

Not very conclusive I'm afraid, but I did say I wasn't an IDE expert!

patrick


_______________________________________________
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

Re: [linux-lvm] read_intr errors

[Patrick Caulfield]

On Fri, Oct 26, 2001 at 12:13:00AM -0700, Erick Calder wrote:
> Patrick,
> 
> looking over the man page on lvreduce it states:
> 
> > lvreduce allows you to reduce the size of a  logical  volume.
> > Be  careful  when reducing a logical volume's size,
> > because data in the reduced part is lost!!!
> 
> the above warning is not conclusive as to whether data loss occurs only when
> the LV is full i.e. it has no choice but to lose data, of if data loss may
> occur regardless i.e. there's no smarts in lvreduce to move data around...
> 
> can you clarify this point and perhaps reword the above for a next release
> of that man page?


What it's warning you about is reducing the size of the LV without first changing
the size of the filesystem that is using it. eg (for reiserfs) you *must*

# resize_reiserfs <blah>
# lvreduce <blah>

Otherwise the filesystem will still think it is the same size as before and try
to read/write off the end of the block device. This is almost guaranteed to
cause problems.
 
> anyhow, I understand what you're suggesting... however it's not clear to me
> what "a little" means... would 1K do? 1M?
> 
> with the above, would I do:
> 
> # lvreduce -l -1 /dev/LVM/mp3z
> 
> to test this theory?

You should reduce it by at least 1 Physical Extent (default is 4Meg), if you
use the lower-case l to lvreduce it will do that for you (Capital L is for
K/Meg/Gigabyes, lowercase l is for PEs) so

# lvreduce -l 1 /dev/LVM/mp3z

Will do the job *BUT YOU MUST RESIZE THE FILESYSTEM FIRST*

If you are using an ext2 filesystem then you can use the e2fsadm command:

# e2fsadm -l -1 /dev/LVM/mp3z



patrick

RE: [linux-lvm] read_intr errors

[Erick Calder]

> What it's warning you about is reducing the size of the LV without first
changing
> the size of the filesystem that is using it.

aha... maybe I could encourage the man page's maintainer to make that point
a little clearer?

> If you are using an ext2 filesystem then you can use the e2fsadm command:
>
> # e2fsadm -l -1 /dev/LVM/mp3z

I performed the above command expecting I would have to do an lvreduce later
but it <gasp> did it for me...  I haven't done a compare against backups to
make sure I didn't lose data ok but I still have the problem... here's the
output (but read beyond):

> # e2fsadm -l -1 /dev/LVM/mp3z
> e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> /dev/LVM/mp3z: 3041/3751936 files (2.0% non-contiguous), 3450293/7502848
blocks
> resize2fs 1.18 (11-Nov-1999)
> Begin pass 3 (max = 229)
> Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> The filesystem on /dev/LVM/mp3z is now 7501824 blocks long.
>
> lvreduce -- WARNING: reducing active logical volume to 28.62 GB
> lvreduce -- THIS MAY DESTROY YOUR DATA (filesystem etc.)
> lvreduce -- doing automatic backup of volume group "LVM"
> lvreduce -- logical volume "/dev/LVM/mp3z" successfully reduced
>
> e2fsadm -- ext2fs in logical volume /dev/LVM/mp3z successfully reduced to
28.62 GB

now, in playing with this I've found that I get these error messages most
consistently while shutting down.  and analysis of /etc/init.d/halt shows
that the errors are produced by an effort to remount / in readonly mode...
the code reads like this:

> #echo "Remounting remaining filesystems (if any) readonly"
> mount | awk '/ext2/ { print $3 }' | while read line; do
>     mount -n -o ro,remount $line
> done

by the time this code is run I've already un-mounted /var/LVM/mp3z and done
a "vgchange -a n"... so in retrospect I can say that the only thing that has
changed (I wasn't having these errors before installing LVM) is that I did a
"pvcreate /dev/hdc"...

is the info above of any use and is there anything else I can try?

1k thx - e

-----Original Message-----
From:	linux-lvm-admin@sistina.com [mailto:linux-lvm-admin@sistina.com] On
Behalf Of Patrick Caulfield
Sent:	Friday, October 26, 2001 1:10 AM
To:	linux-lvm@sistina.com
Subject:	Re: [linux-lvm] read_intr errors

On Fri, Oct 26, 2001 at 12:13:00AM -0700, Erick Calder wrote:
> Patrick,
>
> looking over the man page on lvreduce it states:
>
> > lvreduce allows you to reduce the size of a  logical  volume.
> > Be  careful  when reducing a logical volume's size,
> > because data in the reduced part is lost!!!
>
> the above warning is not conclusive as to whether data loss occurs only
when
> the LV is full i.e. it has no choice but to lose data, of if data loss may
> occur regardless i.e. there's no smarts in lvreduce to move data around...
>
> can you clarify this point and perhaps reword the above for a next release
> of that man page?


What it's warning you about is reducing the size of the LV without first
changing
the size of the filesystem that is using it. eg (for reiserfs) you *must*

# resize_reiserfs <blah>
# lvreduce <blah>

Otherwise the filesystem will still think it is the same size as before and
try
to read/write off the end of the block device. This is almost guaranteed to
cause problems.

> anyhow, I understand what you're suggesting... however it's not clear to
me
> what "a little" means... would 1K do? 1M?
>
> with the above, would I do:
>
> # lvreduce -l -1 /dev/LVM/mp3z
>
> to test this theory?

You should reduce it by at least 1 Physical Extent (default is 4Meg), if you
use the lower-case l to lvreduce it will do that for you (Capital L is for
K/Meg/Gigabyes, lowercase l is for PEs) so

# lvreduce -l 1 /dev/LVM/mp3z

Will do the job *BUT YOU MUST RESIZE THE FILESYSTEM FIRST*

If you are using an ext2 filesystem then you can use the e2fsadm command:

# e2fsadm -l -1 /dev/LVM/mp3z



patrick


_______________________________________________
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

Re: [linux-lvm] read_intr errors

[Patrick Caulfield]

On Fri, Oct 26, 2001 at 02:15:41PM -0700, Erick Calder wrote:
> > What it's warning you about is reducing the size of the LV without first
> changing
> > the size of the filesystem that is using it.
> 
> aha... maybe I could encourage the man page's maintainer to make that point
> a little clearer?

I've added some extra words to the lvreduce man page to help clarify matters,
and make it a little less scary!

 
> > If you are using an ext2 filesystem then you can use the e2fsadm command:
> >
> > # e2fsadm -l -1 /dev/LVM/mp3z
> 
> I performed the above command expecting I would have to do an lvreduce later
> but it <gasp> did it for me...  I haven't done a compare against backups to
> make sure I didn't lose data ok but I still have the problem... here's the
> output (but read beyond):

It'll be fine. e2dsadm does the filesystem AND LV changes in the right order.

> 
> by the time this code is run I've already un-mounted /var/LVM/mp3z and done
> a "vgchange -a n"... so in retrospect I can say that the only thing that has
> changed (I wasn't having these errors before installing LVM) is that I did a
> "pvcreate /dev/hdc"...
> 
> is the info above of any use and is there anything else I can try?

Don't reboot?

I'm out of ideas now, I'll have think....
 

patrick