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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 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/
