[linux-lvm] Find Correct LE Size of ext4 Filesystem (16TB)

[Sebastian Walter]

Hi Matthew,

On 10/09/2013 12:58 AM, matthew patton wrote:

> 
> The whole point of using LVM is to dispense with the malarky of hard disk partitions so I don't know why you're resizing them. If I read your email correctly you're going about this dangerously.> 

Thanks for pointing this out. Now I realize that I used the term
"partition" instead of "filesystem" erroneously (changed subject).

What I initially wanted to do is to extend the filesystem to the whole
size of the underlying physical disks. So first I extended the LV to
fill the disks (19TB). As the second step I wanted to resize the ext4
filesystem to the LV size of 19TB. This last step failed with an error
message saying that tune4fs can't allocate more than 16TB. Setting the
filesystem's size to 16T worked.

Now I have a 16TB filesystem on a 19.18TB logical volume. The additional
3TB are unused on the LV so I want to reduce the LV to the same size as
the filesystem. This way I could use the 3TB for other LVs.

> 3) resize2fs (no args) <LV device>
> 
> Step 3 will resize the FS to as close as the LV size allows and won't let you write past the LV's endpoint like your method makes so easy to screw up when doing the extent calculation. Maybe your maths are always perfect but I wouldn't risk my data for a measly few bytes. Do it the fool-proof way.

I agree with you that resizing the filesystem to the therotical values
of the LV geometry is much too risky.

What would be the fool-proof way? Creating a new filesystem on a 16TB LV
and copying the data from the backup?

Or is it really safe to reduce the LV by some amount - let's say 2.5TB -
and sacrifice 500GB for safety?

Thanks! Sebastian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5045 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20131009/5b452ad3/attachment.p7s>