[linux-lvm] LVM resize broken file system....

[linux-lvm] LVM resize broken file system....

[Another Sillyname]

[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

I had a 487G LVM that contained a single partition and a swap partition.

On the data partition I had 86G free that I needed to use elsewhere.

All the following have been done from a recovery disk so the data is all
still intact.

When I tried to resize to 400G it wouldn't  let me stating below mjnimum
size...

sudo resize2fs -p /dev/pathto/lvmdevice 400G

However mounting it df -h reports

                                                 Size      Used     Free
/dev/pathto/lvmdevice        487G   377G     86G

or in 4k blocks

/dev/pathto/lvmdevice         127571672     98643758    22449438

So I was forced to run the resize2fs in tye default 4k mode

sudo resize2fs -p /dev/pathto/lvmdevice 105000000

This should give me a sufficient overhead and finished correctly

I then did

sudo lvresize -L /dev/pathto/lvmdevice

This also appeared to be successful.

However I can't mount it as it's reporting wrong fs type, bad option etc
error.

I think I've identified the problem as a mismatch on ghe block count.

Even though I resized to 105000000 blocks I now see that df -h reported the
size as 103352144 before I did the  lvresize (I didn't notice at the time)

So I think the discrepancy between the  block count size reported by df at
103352144 and tune2fs at 105000000 is the error.

How can I change the block count number reported by tune2fs from 105000000
to 103352144 that will then allow me to run e2fsck again?

Thanks





-- 
Sent from Tablet

[-- Attachment #2: Type: text/html, Size: 1648 bytes --]

Re: [linux-lvm] LVM resize broken file system....

[Gabriel]

On Sun, Jan 27, 2013 at 8:51 AM, Another Sillyname
<anothersname@googlemail.com> wrote:
> I had a 487G LVM that contained a single partition and a swap partition.
>
> On the data partition I had 86G free that I needed to use elsewhere.
>
> All the following have been done from a recovery disk so the data is all
> still intact.
>
> When I tried to resize to 400G it wouldn't  let me stating below mjnimum
> size...
>
> sudo resize2fs -p /dev/pathto/lvmdevice 400G
>
> However mounting it df -h reports
>
>                                                  Size      Used     Free
> /dev/pathto/lvmdevice        487G   377G     86G
>
> or in 4k blocks
>
> /dev/pathto/lvmdevice         127571672     98643758    22449438
>
> So I was forced to run the resize2fs in tye default 4k mode
>
> sudo resize2fs -p /dev/pathto/lvmdevice 105000000
>
> This should give me a sufficient overhead and finished correctly
>
> I then did
>
> sudo lvresize -L /dev/pathto/lvmdevice
>
> This also appeared to be successful.
>
> However I can't mount it as it's reporting wrong fs type, bad option etc
> error.
>
> I think I've identified the problem as a mismatch on ghe block count.
>
> Even though I resized to 105000000 blocks I now see that df -h reported the
> size as 103352144 before I did the  lvresize (I didn't notice at the time)
>
> So I think the discrepancy between the  block count size reported by df at
> 103352144 and tune2fs at 105000000 is the error.
>
> How can I change the block count number reported by tune2fs from 105000000
> to 103352144 that will then allow me to run e2fsck again?
>
> Thanks

You should use dumpe2fs -h /dev/pathto/lvmdevice | grep -i block and
look for block count and block size. Multiply those two values to
obtain the "grand total" (in bytes) that your filesystem is using. The
lv must be higher than that.

Re: [linux-lvm] LVM resize broken file system....

[Zdenek Kabelac]

Dne 27.1.2013 07:51, Another Sillyname napsal(a):
> I had a 487G LVM that contained a single partition and a swap partition.
>
> On the data partition I had 86G free that I needed to use elsewhere.
>
> All the following have been done from a recovery disk so the data is all still
> intact.
>
> When I tried to resize to 400G it wouldn't  let me stating below mjnimum size...
>
> sudo resize2fs -p /dev/pathto/lvmdevice 400G
>
> However mounting it df -h reports
>

Unsure from where did you get  that  'df -h' reports something sensible about 
total number of blocks in the filesystem ?

IMHO there is nothing in common - it reports just 'usable' space - but
there is no info about filesystem metadata space being used.
(And in fact it's somewhat 'made-up' number)

So using  'df' for anything related to filesystem resize is not going to work.



> Even though I resized to 105000000 blocks I now see that df -h reported the
> size as 103352144 before I did the  lvresize (I didn't notice at the time)
>
> So I think the discrepancy between the  block count size reported by df at
> 103352144 and tune2fs at 105000000 is the error.
>
> How can I change the block count number reported by tune2fs from 105000000 to
> 103352144 that will then allow me to run e2fsck again?
>

I'd strongly advice to use: 'lvresize -r' which should try to do its best to 
fit the filesystem properly in the give size.


Zdenek