<div dir="ltr">Appreciate the response although I realized a messed up large volume lvm requires time and which I didn't have in this case and resorted to backup and recreated volumes all over new . <div><br></div><div>
I realize I went wrong with resize2fs thinking that it would reduce my lvm by 100G but it actually reduced the total volume size to 100G , i-e an lvm of 1.7T</div><div><br></div><div>resize2fs /dev/vg0/data 100G ( i thought it would reduce the by 100G but dropped the block device size to total of 100G )</div>
<div><br></div><div>so to i guess to do this right i should have </div><div><br></div><div>resize2fs /dev/vg0/data 1.6T or (1600G)</div><div><br></div><div>and then lvreduce -n data -L 100G /dev/vg0/data ( to reduce the lvm by 100 ) </div>
<div><br></div><div>I even tried the vgcfgrestore on the archived lvm metadata file but that just restored the metadata (back to original volume size however I still had a bad file system ) .</div><div><br></div><div><br>
</div><div>Tariq</div><div><br></div><div><br><div class="gmail_quote">On Fri, May 18, 2012 at 3:55 PM, Bryn M. Reeves <span dir="ltr"><<a href="mailto:bmr@redhat.com" target="_blank">bmr@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div><div>On 05/18/2012 12:13 AM, Ray Morris wrote:<br>
> Stop. Don't do anything else until you are sure of what to do next.<br>
> You will not lose data by studying. You can lose data by trying to<br>
> fix it.<br>
><br>
>> resize2fs /dev/vg0/data 100G lvreduce -L -100G -n /dev/vg0/data*<br>
><br>
> A 100 GB filesystem needs a block device of around 110 GB. So<br>
> this cut off the end of your filesystem. (The device needs to hold<br>
> the journal as well as the FS, for example.)<br>
<br>
</div>Not with most file systems. When you ask resize2fs to make a file<br>
system 100G it will make it (within rounding limits) 100G's worth of<br>
blocks in length. This is the actual space required on the disk (i.e.<br>
the argument is the size of the file system image not the maximum free<br>
space within it).<br>
<br>
E.g.:<br>
<br>
# lvcreate -L 100M -n l0 tvg0<br>
Logical volume "l0" created<br>
# mke2fs -j /dev/tvg0/l0<br>
mke2fs 1.41.9 (22-Aug-2009)<br>
Filesystem label=<br>
OS type: Linux<br>
Block size=1024 (log=0)<br>
Fragment size=1024 (log=0)<br>
25688 inodes, 102400 blocks<br>
[...]<br>
<br>
102400 1024-byte blocks is exactly 100M (MiB to be pedantic).<br>
<br>
Resize to 50M gives:<br>
<br>
# resize2fs /dev/tvg0/l0 50M<br>
resize2fs 1.41.9 (22-Aug-2009)<br>
Resizing the filesystem on /dev/tvg0/l0 to 51200 (1k) blocks.<br>
The filesystem on /dev/tvg0/l0 is now 51200 blocks long.<br>
<br>
51200 1024 byte blocks is exactly 50MiB.<br>
<div><br>
Regards,<br>
Bryn.<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.12 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a><br>
<br>
</div>iEYEARECAAYFAk+2I6wACgkQ6YSQoMYUY96SlACfTAzVIzeym6iM3fzGhsR0P9YK<br>
iG8Amwfu9AwTnwHvCUddMdzhKxlW0uCA<br>
=+ITm<br>
-----END PGP SIGNATURE-----<br>
<br>
_______________________________________________<br>
linux-lvm mailing list<br>
<a href="mailto:linux-lvm@redhat.com" target="_blank">linux-lvm@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/linux-lvm" target="_blank">https://www.redhat.com/mailman/listinfo/linux-lvm</a><br>
read the LVM HOW-TO at <a href="http://tldp.org/HOWTO/LVM-HOWTO/" target="_blank">http://tldp.org/HOWTO/LVM-HOWTO/</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><i style="background-color:rgb(255,0,0);color:rgb(0,102,0)">Tariq Wali.</i><span><span style="background-color:rgb(255,255,153)"></span></span><br>
</div><br>
</div></div>