From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx14.extmail.prod.ext.phx2.redhat.com [10.5.110.19]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q950mjEh021237 for ; Thu, 4 Oct 2012 20:48:45 -0400 Received: from mail.bmsi.com (www.bmsi.com [24.248.44.156]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q950miCJ007473 for ; Thu, 4 Oct 2012 20:48:44 -0400 Received: from sdg.bmsi.com (sdg.bmsi.com [192.168.9.34] (may be forged)) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q94Jxjb8016224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Oct 2012 15:59:46 -0400 Message-ID: <506DEAB1.8090707@bmsi.com> Date: Thu, 04 Oct 2012 15:59:45 -0400 From: Stuart D Gathman MIME-Version: 1.0 References: <39598.78.154.109.125.1345731038.squirrel@yellowside.org.uk> <50376BB7.7010008@bmsi.com> <503C8ABB.10401@redhat.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010701070408090607020600" Subject: Re: [linux-lvm] lvextend NEVER works but screws up Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: To: linux-lvm@redhat.com This is a multi-part message in MIME format. --------------010701070408090607020600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Let me remind people that on RHEL5, running e2fsck on an ext4 filesystem will actually destroy data! Always use fsck, which runs either e2fsck or e4fsck when e4fsprogs is installed. On newer systems, where ext4 support is not tacked on as e4fsprogs, e2fsck handles both (but is it still a good habit to use fsck to run the proper checker). On 10/04/2012 02:32 AM, tariq wali expounded in part: > > resize2fs /dev/vg0/bin-logs > resize2fs 1.39 (29-May-2006) > resize2fs: Filesystem has unsupported feature(s) while > trying to open > /dev/vg0/bin-logs > Couldn't find valid filesystem superblock. > > #this is where I would get psyched , i did the same thing > to all my ext2/3 > filesystems and have extended file systems online without > an issue for > years ..but did I fforget the file system type this time , > yes indeed I for > got we have started doing ext4 on all our new servers and > didn't realise > ext4 fancies it's own bells and whistles .. > > I ran the all new resize4fs as suggested by Stuart , and > it made my day in > fact it made for the whole week's frustration :) > > resize4fs /dev/vg0/logs > resize4fs 1.41.12 (17-May-2010) > Filesystem at /dev/vg0/logs is mounted on /bin-logs; > on-line resizing > required > old desc_blocks = 7, new_desc_blocks = 9 > Performing an on-line resize of /dev/vg0/logs to 37408768 > (4k) blocks. > > The filesystem on /dev/vg0/logs is now 37408768 blocks long. > --------------010701070408090607020600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Let me remind people that on RHEL5, running e2fsck on an ext4 filesystem will actually destroy data!  Always
use fsck, which runs either e2fsck or e4fsck when e4fsprogs is installed.  On newer systems, where ext4 support is not tacked on as e4fsprogs, e2fsck handles both (but is it still a good habit to use fsck to run the proper checker).

On 10/04/2012 02:32 AM, tariq wali expounded in part:

resize2fs /dev/vg0/bin-logs
resize2fs 1.39 (29-May-2006)
resize2fs: Filesystem has unsupported feature(s) while trying to open
/dev/vg0/bin-logs
Couldn't find valid filesystem superblock.

#this is where I would get psyched , i did the same thing to all my ext2/3
filesystems and have extended file systems online without an issue for
years ..but did I fforget the file system type this time , yes indeed I for
got we have started doing ext4 on all our new servers and didn't realise
ext4 fancies it's own bells and whistles ..

I ran the all new resize4fs as suggested by Stuart , and it made my day in
fact it made for the whole week's frustration :)

resize4fs /dev/vg0/logs
resize4fs 1.41.12 (17-May-2010)
Filesystem at /dev/vg0/logs is mounted on /bin-logs; on-line resizing
required
old desc_blocks = 7, new_desc_blocks = 9
Performing an on-line resize of /dev/vg0/logs to 37408768 (4k) blocks.

The filesystem on /dev/vg0/logs is now 37408768 blocks long.

--------------010701070408090607020600--