Hi folks,


I have reduced my lv size from 12G to 6G

Now, when I am trying to mount it is showing :


[root@ ~]# mount /dev/newvg/newlv /lvm/
mount: wrong fs type, bad option, bad superblock on /dev/mapper/newvg-newlv,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so


I have also tried this :
mount -t ext4 /dev/newvg/newlv /lvm/


Can someone tell me, How safe it is to reduce LV?


Thanks in advance.
-Mitter

It's quite safe to reduce or extend the size of LVM. You just have to take care of the filesystem that resides within.
As Linux goes it just takes logical volumes as paritions. And when you would shrink a partition you would first shrink the filesystem within. Then shrink the partition. Same goes for LVM.

So you can do 2 things now. Either extend the lv to its orginal size, then shrink the filesystem, then shrink the lv.
Or just try to shrink the filesystem inside the lv.

Did you follow the correct procedure to shrink your logical volume?

http://tldp.org/HOWTO/LVM-HOWTO/reducelv.html

As zhjim already mentioned, you have to resize the filesystem before you resize the LV that contains that filesystem.

Hi zhjim, haertig,

These are the steps which I have followed :

Step 1 :
[root@mail lvm]# lvdisplay /dev/mapper/newvg-newlv
--- Logical volume ---
LV Path /dev/newvg/newlv
LV Name newlv
VG Name newvg
LV UUID uRX9yO-rbgE-fGRJ-YQFu-uKHQ-fjnp-yHnus3
LV Write Access read/write
LV Creation host, time mail.mitters.in, 2013-09-20 11:24:29 +0530
LV Status available
# open 1
LV Size 12.00 GiB
Current LE 3072
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:2

[COLOR="rgb(255, 0, 255)"]Step 2 : [/COLOR]
[root@mail ~]# mkfs.ext4 /dev/newvg/newlv
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
786432 inodes, 3145728 blocks
157286 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=3221225472
96 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
[root@mail ~]#

Step 3 : mount /dev/newvg/newlv /lvm/

Step 3.1 : I have created some folder for testing.
[root@mail lvm]# ll
total 28
drwx------. 2 root root 16384 Sep 20 11:27 lost+found
drwxr-xr-x. 2 root root 4096 Sep 20 11:35 test
drwxr-xr-x. 2 root root 4096 Sep 20 11:35 test2
-rw-r--r--. 1 root root 171 Sep 20 11:36 test.txt
[root@mail lvm]#

[COLOR="rgb(255, 0, 255)"]Step 4 : [/COLOR]
[root@mail ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_vm0-lv_root
11G 3.8G 6.4G 38% /
tmpfs 288M 72K 288M 1% /dev/shm
/dev/sda1 485M 38M 423M 9% /boot
/dev/sr0 4.1G 4.1G 0 100% /media/CentOS_6.4_Final
/dev/mapper/newvg-newlv
12G 158M 12G 2% /lvm

[COLOR="rgb(255, 0, 255)"]Step 5 : [/COLOR]
[root@mail ~]# umount /lvm/

[COLOR="rgb(255, 0, 255)"]Step 6 : [/COLOR]
[root@mail ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_vm0-lv_root
11G 3.8G 6.4G 38% /
tmpfs 288M 72K 288M 1% /dev/shm
/dev/sda1 485M 38M 423M 9% /boot
/dev/sr0 4.1G 4.1G 0 100% /media/CentOS_6.4_Final

[COLOR="rgb(255, 0, 255)"]Step 7 : [/COLOR]
[root@mail ~]# lvreduce -L 6G /dev/mapper/newvg-newlv
WARNING: Reducing active logical volume to 6.00 GiB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce newlv? [y/n]: y
Reducing logical volume newlv to 6.00 GiB
Logical volume newlv successfully resized

[COLOR="rgb(255, 0, 255)"]Step 8 :[/COLOR]
[root@mail ~]# resize2fs -p /dev/mapper/newvg-newlv
resize2fs 1.41.12 (17-May-2010)
Please run 'e2fsck -f /dev/mapper/newvg-newlv' first.


[COLOR="rgb(255, 0, 255)"]Step 9 :[/COLOR]
[root@mail ~]# mount /dev/mapper/newvg-newlv /lvm
mount: wrong fs type, bad option, bad superblock on /dev/mapper/newvg-newlv,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

[COLOR="rgb(255, 0, 255)"]Step 10 :[/COLOR]
[root@mail ~]# e2fsck -f /dev/mapper/newvg-newlv
e2fsck 1.41.12 (17-May-2010)
Error reading block 1606401 (Invalid argument). Ignore error<y>? yes

Force rewrite<y>? yes

Error writing block 1606401 (Invalid argument). Ignore error<y>? yes

Superblock has an invalid journal (inode 8).
Clear<y>? yes

*** ext3 journal has been deleted - filesystem is now ext2 only ***

Superblock has_journal flag is clear, but a journal inode is present.
Clear<y>? yes

The filesystem size (according to the superblock) is 3145728 blocks
The physical size of the device is 1572864 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

Error writing block 1606401 (Invalid argument). Ignore error<y>? yes

[COLOR="rgb(255, 0, 255)"]Step 10: [/COLOR]

[root@mail ~]# mount /dev/mapper/newvg-newlv /lvm
mount: wrong fs type, bad option, bad superblock on /dev/mapper/newvg-newlv,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

[COLOR="rgb(255, 0, 255)"][root@mail ~]# dmesg |tail[/COLOR]
sdb: sdb1
sdb: sdb1
EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts:
SELinux: initialized (dev dm-2, type ext4), uses xattr
EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts:
SELinux: initialized (dev dm-2, type ext4), uses xattr
EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts:
SELinux: initialized (dev dm-2, type ext4), uses xattr
EXT4-fs (dm-2): bad geometry: block count 3145728 exceeds size of device (1572864 blocks)
EXT4-fs (dm-2): bad geometry: block count 3145728 exceeds size of device (1572864 blocks)


Please help.

-Mitter

Do step 8 before step 7

When resize2fs displays that "Please run 'e2fsck ...' first" message, it did not resize the filesystem. resize2fs refuses to run on filesystems that were not checked since the last time they were mounted (Mount count is non-zero).

I have to ask WHY you answered "yes" to the question below?

You must resize the filesystem FIRST, then resize the logical volume SECOND. You did just the opposite. The lvreduce command tried to warn you, but you ignored the warning.

At this point, your filesystem is most likely corrupted. Possibly beyond repair. I don't know about that part, as I've never done what you did to have any personal experience with that.

I think it would be best at this point to restore your damaged filesystem from backup. I wouldn't mess with any other repair attempts at this point. Most likely, they would be a waste of time and fruitless in the end.

If the LV was originally contiguous, you could just resize it back to the original size and very likely find that your filesystem was intact. If the LV was non-contiguous, then you would probably not get back the same extents that it had originally, and the missing parts of your filesystem would be essentially unrecoverable.

Hi zhjim,

If I try to do Step 8 before Step 7, It says :

[root@mail ~]# resize2fs -p /dev/mapper/newvg-newlv
resize2fs 1.41.12 (17-May-2010)
The filesystem is already 3145728 blocks long. Nothing to do!


Please suggest.

Thanks!
-MITTER

Thanks to brianmcgee and all above.


useful steps in his post : http://www.linuxquestions.org/questi...taloss-557746/


-MITTER

resize2fs can't magically determine what new, smaller size you want. You have to tell it. Given the consequences of leaving the filesystem a bit too large for its container, the usual recommendation is to shrink the filesystem to a size somewhat smaller than it will ultimately be, resize the container, then resize the filesystem again to the default of filling the container:

1 members found this post helpful.

Thanks rknichols,

Resolved.

-MITTER