[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Resizing partitions on a headless server



Gary Dale <garydale@torfree.net> writes:

> On 14/06/15 09:12 AM, Pascal Hambourg wrote:
>> csanyipal@gmail.com a écrit :
>>> Hello,
>>>
>>> on my headless Debian GNU/Linux Jessie server I want to resize
>>> partitions.
>> Why ? The use of LVM should avoid the need to resize partitions (PVs).
>>
>>> root@b2:~# e2fsck -f /dev/mapper/bubba-storage
>>> e2fsck 1.42.12 (29-Aug-2014)
>>> Pass 1: Checking inodes, blocks, and sizes
>>> Pass 2: Checking directory structure
>>> Pass 3: Checking directory connectivity
>>> Pass 4: Checking reference counts
>>> Pass 5: Checking group summary information
>>> Bubba_home: 114439/59703296 files (0.4% non-contiguous), \
>>> 4001648/119386112 blocks
>>>
>>> At this step I think I forgot to run again:
>>> root@b2:~# resize2fs -p /dev/mapper/bubba-storage 20G
>>>
>>> root@b2:~# lvresize --size 2.1G /dev/mapper/bubba-storage
>>>    Rounding size to boundary between physical extents: 2.10 GiB
>>>      WARNING: Reducing active logical volume to 2.10 GiB
>>>        THIS MAY DESTROY YOUR DATA (filesystem etc.)
>>>        Do you really want to reduce storage? [y/n]: y
>>>          Size of logical volume bubba/storage changed from 455.42 GiB
>>>    (116588 extents) to 2.10 GiB (538 extents).
>>>      Logical volume storage successfully resized
>>>
>>> Furthermore, I was wrong when I determined the --size to 2.1G in the
>>> command abowe, because I wanted to write 20.1G instead.
>> The bad news is that you probably screwed the filesystem. LVM provides
>> flexibility over plain partitions, but at the cost of complexity and is
>> less tolerant to such a mistake.
>>
>> With a plain partition, all you would have to do to fix the mistake is
>> to extend the reduced partition (not the filesystem) to its original
>> size. However, with LVM, if you extend a reduced LV to its original
>> size, nothing guarantees that it will use the same physical blocks as
>> before. You can try, but it may not restore the filesystem's integrity.
>> Run fsck to check the damage.
>>
>> Edit : check in /etc/lvm/backup for a metadata backup of the previous
>> situation of the VG "bubba". Using it to restore the LV is beyond my
>> knowledge, but if your data is important and you don't have a backup
>> (sounds like an oxymoron), my advice is don't touch anything until you
>> find how to restore the LV. Otherwise, just extend the LV and recreate
>> the filesystem on it.
>>
>>> Now what can I do to correct the partitions?
>> There is no partition to correct. The problem is in the LV bubba/storage
>> and its filesystem.
>>
>>
> If you read the original post, it looks like the e2rsize
> failed. Therefor the only problem is the partition table is wrong.

I think now is everything fixed, the partition table also. Am I right?
How can be sure? After reboot I can login as non root user, I can find
my ( not so valuable ) data on /home, ..

-- 
Regards from Pal


Reply to: