[linux-lvm] How to fix missmatch between VG-size and LV-size?
Fredrik Skog
fredrik.skog at rodang.se
Thu Mar 31 15:06:39 UTC 2011
Hello,
If I ever get all this data back I will definitely try to either RAID it or
make a backup of the most importatnt stuff on the volume.
I have now run e2fsck -n -t -v /dev/vgftp/lvftp successfully. It gave me the
following output. I'm not really sure what it means, but I think it looks
pretty ok. Do you think it's ok to do this for real now?
################
# e2fsck -n -t -v /dev/vgftp/lvftp
e2fsck 1.41.10 (10-Feb-2009)
/dev/vgftp/lvftp contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Running additional passes to resolve blocks claimed by more than one
inode...
Pass 1B: Rescanning for multiply-claimed blocks
Multiply-claimed block(s) in inode 51036510: 102452460
Multiply-claimed block(s) in inode 96436268: 203786736
Multiply-claimed block(s) in inode 122208259: 244427502
Multiply-claimed block(s) in inode 195693509: 396636221
Multiply-claimed block(s) in inode 331595778: 665071629
Pass 1C: Scanning directories for inodes with multiply-claimed blocks
Pass 1D: Reconciling multiply-claimed blocks
(There are 5 inodes containing multiply-claimed blocks.)
File /XX/XXXXXXXX.XXX (inode #51036510, mod time Sun Apr 30 03:39:57 2006)
has 1 multiply-claimed block(s), shared with 0 file(s):
Multiply-claimed blocks already reassigned or cloned.
File /XXXX/XXXXXXX.XXX (inode #96436268, mod time Sun Feb 25 19:15:11 2007)
has 1 multiply-claimed block(s), shared with 0 file(s):
Multiply-claimed blocks already reassigned or cloned.
File /XXXX/XXXX/XX.XXX (inode #122208259, mod time Sun Jul 15 18:37:56 2007)
has 1 multiply-claimed block(s), shared with 0 file(s):
Multiply-claimed blocks already reassigned or cloned.
File /XXX/XXXX.XXX (inode #195693509, mod time Sat Oct 18 01:00:53 2008)
has 1 multiply-claimed block(s), shared with 0 file(s):
Multiply-claimed blocks already reassigned or cloned.
File /XX/XXX.XXX (inode #331595778, mod time Thu Mar 19 00:51:54 2009)
has 1 multiply-claimed block(s), shared with 0 file(s):
Multiply-claimed blocks already reassigned or cloned.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap
differences: -(244--268) -(98548--98572) -(164084--164108) -(229620--229644)
-(295156--295180) -(819444--819468) -(884980--885004) -(1605876--1605900) -(2654452--2654476)
-(4096244--4096268) -(7962868--7962892) -(11239668--11239692)
+(14601899--14601923)
+(14601949--14602273) -(20480244--20480268) -(23888116--23888140) -472222192
-512862958 -639323372 -933507085 -933507133
Fix? no
/dev/vgftp/lvftp: ********** WARNING: Filesystem still has errors **********
308343 inodes used (0.06%)
56220 non-contiguous files (18.2%)
206 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 247855/206685/61
1006593162 blocks used (99.57%)
0 bad blocks
82 large files
290797 regular files
17537 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
308334 files
Memory used: 736k/309504k (407k/330k), time: 20076.40/1223.57/795.83
I/O read: 133788MB, write: 0MB, rate: 6.66MB/s
######################
I will try to copy the most important stuff off of the volume before i try
this though.
Before running resize2fs later, how do I figure the right size of the
filesystem out? Without risking shrinking it too much.
Thanks
/Fredrik Skog
----- Original Message -----
From: "Ray Morris" <support at bettercgi.com>
To: <linux-lvm at redhat.com>
Sent: Wednesday, March 30, 2011 5:04 PM
Subject: Re: [linux-lvm] How to fix missmatch between VG-size and LV-size?
> Yes i sounds like it's time to fsck, then if needed
> resize2fs to the proper size. It would be best to
> mount it read only only and copy whatever data copies
> to be safe. 4TB is a lot of data, but then again it's
> only $130 worth of consumer drives to back it up.
> --
> Ray Morris
> support at bettercgi.com
>
> Strongbox - The next generation in site security:
> http://www.bettercgi.com/strongbox/
>
> Throttlebox - Intelligent Bandwidth Control
> http://www.bettercgi.com/throttlebox/
>
> Strongbox / Throttlebox affiliate program:
> http://www.bettercgi.com/affiliates/user/register.php
>
>
>
>
> On Wed, 30 Mar 2011 02:27:49 +0200
> "Fredrik Skog" <fredrik.skog at rodang.se> wrote:
>
>>
>> ----- Original Message -----
>> From: "Stuart D. Gathman" <stuart at bmsi.com>
>> To: "LVM general discussion and development" <linux-lvm at redhat.com>
>> Sent: Wednesday, March 30, 2011 12:14 AM
>> Subject: Re: [linux-lvm] How to fix missmatch between VG-size and
>> LV-size?
>>
>> >SNIP>
>>
>> >> I can run LVM commands fine now after the reboot and the output
>> >> from pvdisplay and lvdisplay is like i posted earlier.
>> >> How can i revert this in a safe way? I was thinking of just
>> >> removing the PV and do a vgcfgrestore to "before" the lvextend.
>> >> But since lvdisplay says the volume is 4.16TiB and pvdisplay says
>> >> 5.59TiB something is wrong? Or am I missing something?
>>
>> >SNIP>
>>
>> >> Is it better to do a e2fsck now?
>>
>> > That is probably the only way to salvage what is left of your
>> > filesystem, but don't do it until we find out whether the LV is the
>> > old or the new size.
>> > I suspect the LV will be the new size, but the filesystem may still
>> > show the old size. Since the resize2fs should be just adding free
>> > space, there may not be any data loss. e2fsck would fix the (now
>> > corrupt) free space, and you can extend again.
>>
>> I just added all the segments of the LV from an old backed up config
>> file. It adds up to 3,856TB, so I guess you were right and i assumed
>> wrong. The old LV was about 3,8TB and the new is about 4,16TB or
>> about 400GB bigger than before as expected by lvextend -L+400G.
>>
>> Also it tells me I have 1,43TiB free wich is 5,59TiB - 4,16TiB. It
>> also looks right.
>>
>> maybe I should try an e2fsck now?
>>
>> again, thanks for your time
>>
>> /Fredrik Skog
>>
>> >
>> > --
>> > Stuart D. Gathman <stuart at bmsi.com>
>> > Business Management Systems Inc. Phone: 703 591-0911 Fax: 703
>> > 591-6154
>> > "Confutatis maledictis, flammis acribus addictis" - background song
>> > for a Microsoft sponsored "Where do you want to go from here?"
>> > commercial.
>> >
>> > _______________________________________________
>> > linux-lvm mailing list
>> > linux-lvm at redhat.com
>> > https://www.redhat.com/mailman/listinfo/linux-lvm
>> > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm at redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
More information about the linux-lvm
mailing list