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

[Sebastian Walter]

Hi list,

It took me a while to get the server off from production, but finally
Matthew's method worked. I shrank the filesystem to 15TB, then set up
the LV to exactly 16TB and finally expanded the filesystem to the size
of the LV.

Thanks! Many regards, Sebastian

On 10/09/2013 11:42 AM, Gabriel wrote:
> I think what Matthew is saying is that you should first shrink your
> filesystem to a smaller size (15.8 TiB), then adjust the LV size to 16
> TiB (this is safe because the filesystem above is smaller) and finally
> resize the filesystem to the LV size (resize2fs /your/filesystem).
> This is a much safer approach and leaves you with no unused space.
> 
> On Wed, Oct 9, 2013 at 10:57 AM, Sebastian Walter
> <sebastian.walter at fu-berlin.de> wrote:
>> 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
>>
>>
>> _______________________________________________
>> 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/
> 


-- 
Dipl.-Geol. Sebastian Walter
Freie Universitaet Berlin - Institute of Geological Sciences
Planetary Sciences and Remote Sensing
Malteserstrasse 74-100 - 12249 Berlin, Germany
Phone: +49 30 838 70541

-------------- 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/20131107/4f565501/attachment.p7s>