7> Run "resize2fs /dev/vgftp/lvftp" > resize2fs 1.41.10 (10-Feb-2009) > Resizing the filesystem on /dev/vgftp/lvftp to 1115800576 (4k) > blocks > Resizing the filesystem on /dev/vgftp/lvftp to 1115800576 (4k) > blocks 8> Here it all hangs. I cant do anything with the filesystem or LVM. 8> every You can expect resize2fs to take a couple of hours on a 4 TB filesystem, so the "crash" may well be nothing but impatience. > If i do a lvreduce i fear something will break. > Is it better to do a e2fsck now? The problem that we know about is that the resize2fs was interrupted. Reports defer in the level in danger in that, but definitely we want to get the filesystem consistent and small enough before we pull the block device out from underneath it. So yes, you need a passing e2fsck before an lvreduce at this points. The safest thing to do would be make a copy of at least the LV, if not both PVs, so you can get back to where you are if needed. That's almost always the first best step for any kind of data recovery type of effort. Once you have a copy or have checked that your backups are Ok, you can proceed with e2fsck. After e2fsck passes, you can try to pvmove the extents off of the new drive, if you wish. If the LV won't fit on the old drive, you'll need to resize2fs and lvreduce to make it fit. It can be hard to know just how big to make the LV for a given FS size, due to filesystem overhead and such. A safe way to do it would be to resize2fs as small as possible first. That'll probably give you at least 10%-20% of margin between the size of the FS and the size of the PV. Then resize the LV to match the PV. Once the LV is at it's final size, resize2fs to max. Check that your LV is in fact the same size as it was before your lvextend and the output of "history". It sounds like either a) you didn't run exactly the commands that you are reporting or b) the LV is in fact larger than it used to be. If you ran lvextend to increase the size of the LV and did not reduce it after, a crash during resize2fs isn't going to shrink it automagically. Also, if it were at the old size, it probably wouldn't be on both PVs. Therefore, the LV probably actually is 400GB larger than it used to be. -- Ray Morris support@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 Tue, 29 Mar 2011 23:56:03 +0200 "Fredrik Skog" <fredrik.skog@rodang.se> wrote: > But since lvdisplay says the volume is 4.16TiB and pvdisplay says > 5.59TiB something is wrong? Or am I missing something? _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
