Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #266449 > unrolled thread

Resizing LVM partitions

Back to article view | Back to linux.debian.user

Contents

  Resizing LVM partitions skoric@uns.ac.rs - 2024-01-22 16:00 +0100
    Re: Resizing LVM partitions Alain D D Williams <addw@phcomp.co.uk> - 2024-01-22 16:20 +0100
      Re: Resizing LVM partitions Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-22 16:40 +0100
        Re: Resizing LVM partitions Alain D D Williams <addw@phcomp.co.uk> - 2024-01-22 16:50 +0100
          Re: Resizing LVM partitions <tomas@tuxteam.de> - 2024-01-22 19:00 +0100
            Re: Resizing LVM partitions Miroslav Skoric <skoric@uns.ac.rs> - 2024-01-22 23:20 +0100
              Re: Resizing LVM partitions <tomas@tuxteam.de> - 2024-01-23 06:50 +0100
              Re: Resizing LVM partitions Andy Smith <andy@strugglers.net> - 2024-01-23 07:40 +0100
                Re: Resizing LVM partitions Miroslav Skoric <skoric@uns.ac.rs> - 2024-01-24 00:40 +0100
                  Re: Resizing LVM partitions Greg Wooledge <greg@wooledge.org> - 2024-01-24 00:50 +0100
                    Re: Resizing LVM partitions <tomas@tuxteam.de> - 2024-01-24 06:50 +0100
                      Re: Resizing LVM partitions Greg Wooledge <greg@wooledge.org> - 2024-01-24 13:10 +0100
                    Re: Resizing LVM partitions Miroslav Skoric <skoric@uns.ac.rs> - 2024-01-24 23:10 +0100
                      Re: Resizing LVM partitions Greg Wooledge <greg@wooledge.org> - 2024-01-24 23:30 +0100
                        Re: Resizing LVM partitions Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-25 15:20 +0100
                        Re: Resizing LVM partitions Miroslav Skoric <skoric@uns.ac.rs> - 2024-01-26 13:40 +0100
                  Re: Resizing LVM partitions Max Nikulin <manikulin@gmail.com> - 2024-01-24 03:30 +0100
                    Re: Resizing LVM partitions Miroslav Skoric <skoric@uns.ac.rs> - 2024-01-24 23:20 +0100
                    On the deprecation of separate /usr (Was: Re: Resizing LVM  partitions) Andy Smith <andy@strugglers.net> - 2024-01-24 23:30 +0100
                  Re: Resizing LVM partitions Andy Smith <andy@strugglers.net> - 2024-01-24 13:10 +0100
          Re: Resizing LVM partitions Miroslav Skoric <skoric@uns.ac.rs> - 2024-01-22 23:20 +0100
            Re: Resizing LVM partitions Greg Wooledge <greg@wooledge.org> - 2024-01-22 23:30 +0100
              Re: Resizing LVM partitions Miroslav Skoric <skoric@uns.ac.rs> - 2024-01-24 00:40 +0100
      Re: Resizing LVM partitions Greg Wooledge <greg@wooledge.org> - 2024-01-22 17:10 +0100
        Re: Resizing LVM partitions <tomas@tuxteam.de> - 2024-01-22 19:10 +0100
          Re: Resizing LVM partitions Greg Wooledge <greg@wooledge.org> - 2024-01-22 19:50 +0100
          Re: Resizing LVM partitions Miroslav Skoric <skoric@uns.ac.rs> - 2024-01-24 00:40 +0100
        Re: Resizing LVM partitions Miroslav Skoric <skoric@uns.ac.rs> - 2024-01-24 00:40 +0100
      Re: Resizing LVM partitions Gremlin <scott-andrews@columbus.rr.com> - 2024-01-22 19:20 +0100
        Re: Resizing LVM partitions Greg Wooledge <greg@wooledge.org> - 2024-01-22 19:50 +0100
      Re: Resizing LVM partitions Miroslav Skoric <skoric@uns.ac.rs> - 2024-01-22 23:20 +0100

Page 2 of 2 — ← Prev page 1 [2]

#266478

On 1/22/24 4:40 PM, Alain D D Williams wrote:
> On Mon, Jan 22, 2024 at 10:29:55AM -0500, Stefan Monnier wrote:
>>> lvextend --size +1G --resizefs /dev/mapper/localhost-home
>>>
>>> Ie get lvextend to do the maths & work it out for me.
>>>
>>> Those who are cleverer than me might be able to tell you how to get it right
>>> first time!
>>
>> lvreduce --size -50G --resizefs /dev/mapper/localhost-home
> 
> Oh, even better. It is a long time since I looked at than man page.
> 
> Does this still need to be done with the file system unmounted or can it be
> done with an active file system these days ?
> 

As I need to extend & resize more than one LV in the file system (/, 
/usr, and /var), should they all need to be unmounted before the 
operation? As I remember, it is ext3 system on that comp.

[toc] | [prev] | [next] | [standalone]

#266480

On Mon, Jan 22, 2024 at 10:41:57PM +0100, Miroslav Skoric wrote:
> As I need to extend & resize more than one LV in the file system (/, /usr,
> and /var), should they all need to be unmounted before the operation? As I
> remember, it is ext3 system on that comp.

Whaaaaat??  I don't think these words mean what you think they mean.

An LV is a logical volume, which is like a virtual partition.  It's a
block device, like /dev/sda2.  You can use an LV the same way you would
use a partition -- you can use it for swap space, or a file system, or
other purposes.

A file system is a mountable directory structure that you can put inside
a partition, or an LV.  File system types include ext4, ext3, xfs, vfat,
and so on.

If your system has separately mounted file systems for /, /usr and
/var and you want to shrink ALL of them, then yes, you would need to
unmount all three of them, shrink them, then (re)boot.  You can't
unmount / during normal operations, so the only ways to shrink / would
involved booting in a special way, either with some external medium,
or with specific kernel parameters.  Thus, you'd typically reboot to
get back to normal operations afterward.

However, if you're in a position where you think you need to make
dramatic changes to FOUR of your mounted file systems, perhaps you
might want to consider restarting from scratch.  Ponder why you have
separate file systems at all.  Are they really giving you a benefit?
Have you ever filled up one of them and thought "Oh wow, I am *so*
glad I separated these file systems so I didn't fill up ___ as well!"
Or are they just giving you grief with no benefits?

[toc] | [prev] | [next] | [standalone]

#266536

On 1/22/24 11:21 PM, Greg Wooledge wrote:
> On Mon, Jan 22, 2024 at 10:41:57PM +0100, Miroslav Skoric wrote:
>> As I need to extend & resize more than one LV in the file system (/, /usr,
>> and /var), should they all need to be unmounted before the operation? As I
>> remember, it is ext3 system on that comp.
> 
> Whaaaaat??  I don't think these words mean what you think they mean.
> 
> An LV is a logical volume, which is like a virtual partition.  It's a
> block device, like /dev/sda2.  You can use an LV the same way you would
> use a partition -- you can use it for swap space, or a file system, or
> other purposes.
> 
> A file system is a mountable directory structure that you can put inside
> a partition, or an LV.  File system types include ext4, ext3, xfs, vfat,
> and so on.
> 

Sorry for my ignorance regarding terminology, I mix terms sometimes :-)

> If your system has separately mounted file systems for /, /usr and
> /var and you want to shrink ALL of them, then yes, you would need to
> unmount all three of them, shrink them, then (re)boot.  You can't
> unmount / during normal operations, so the only ways to shrink / would
> involved booting in a special way, either with some external medium,
> or with specific kernel parameters.  Thus, you'd typically reboot to
> get back to normal operations afterward.
> 

Let me clarify: I did not plan to shrink all of those, but rather just 
one (/home). The other three (/, /usr, and /var) shall be extended from 
the released space.

I managed to locate the first CD of my very old initial installation set 
(squeeze). However, booting from that one did not help me to get /home 
available for shrinking. See later what I did instead.

> However, if you're in a position where you think you need to make
> dramatic changes to FOUR of your mounted file systems, perhaps you
> might want to consider restarting from scratch.  Ponder why you have
> separate file systems at all.  Are they really giving you a benefit?
> Have you ever filled up one of them and thought "Oh wow, I am *so*
> glad I separated these file systems so I didn't fill up ___ as well!"
> Or are they just giving you grief with no benefits?
> 
> 

Well I belong to those who are going to exercise any possible way to 
prolong the life of an existing installation, no matter how old it is. 
In my case it started from squeeze a decade or more ago and gradually 
upgraded during the years. And I knew that some years ago I resized the 
file system because of similar reasons, and that worked at the time. But 
the procedure disappeared from memory :-)

Reinstalling from scratch is always possible, of course.

[toc] | [prev] | [next] | [standalone]

#266458

On Mon, Jan 22, 2024 at 03:17:36PM +0000, Alain D D Williams wrote:
> The shrinking of /home is the hard part. You MUST first unmount /home, then
> resize the file system, then resize the logical volume.

Before doing any of that, one should check the volume group and see
if there are unallocated hunks of free space that can simply be assigned
to the root LV.

One of the fundamental *reasons* to use LVM is to leave a bunch of space
unallocated, and assign it to whatever needs it later, once the storage
needs become known.  Leaving some unallocated space also allows the
use of snapshots, which are nice when doing backups.

I heard someone say, once, that the Debian installer will assign all of
the space in a VG during installation, if you follow its "guided" path.
This is a tragedy, if it's still true.

[toc] | [prev] | [next] | [standalone]

#266463

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jan 22, 2024 at 11:02:06AM -0500, Greg Wooledge wrote:
> On Mon, Jan 22, 2024 at 03:17:36PM +0000, Alain D D Williams wrote:
> > The shrinking of /home is the hard part. You MUST first unmount /home, then
> > resize the file system, then resize the logical volume.
> 
> Before doing any of that, one should check the volume group and see
> if there are unallocated hunks of free space that can simply be assigned
> to the root LV.

Ah, forgot to say: "pvdisplay -m" will give you a "physical" map of
your physical volume. So you get an idea what is where and where
you find gaps.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#266467

On Mon, Jan 22, 2024 at 07:01:13PM +0100, tomas@tuxteam.de wrote:
> On Mon, Jan 22, 2024 at 11:02:06AM -0500, Greg Wooledge wrote:
> > On Mon, Jan 22, 2024 at 03:17:36PM +0000, Alain D D Williams wrote:
> > > The shrinking of /home is the hard part. You MUST first unmount /home, then
> > > resize the file system, then resize the logical volume.
> > 
> > Before doing any of that, one should check the volume group and see
> > if there are unallocated hunks of free space that can simply be assigned
> > to the root LV.
> 
> Ah, forgot to say: "pvdisplay -m" will give you a "physical" map of
> your physical volume. So you get an idea what is where and where
> you find gaps.

A volume group (VG) may be comprised of one or more physical volumes
(PV), and the free space would be counted at the VG level.  So I'd suggest
"vgdisplay" instead.  This tells you how many "PE" (physical extents,
aka hunks of space) are allocated, and how many are free.

[toc] | [prev] | [next] | [standalone]

#266534

On 1/22/24 7:01 PM, tomas@tuxteam.de wrote:
> 
> Ah, forgot to say: "pvdisplay -m" will give you a "physical" map of
> your physical volume. So you get an idea what is where and where
> you find gaps.
> 


"pvdisplay -m" provided some idea that there was some free space but (if 
I am not wrong) not how much in MB, GB, or else.

I found gvdisplay more precise in that direction.

[toc] | [prev] | [next] | [standalone]

#266535

On 1/22/24 5:02 PM, Greg Wooledge wrote:
> On Mon, Jan 22, 2024 at 03:17:36PM +0000, Alain D D Williams wrote:
>> The shrinking of /home is the hard part. You MUST first unmount /home, then
>> resize the file system, then resize the logical volume.
> 
> Before doing any of that, one should check the volume group and see
> if there are unallocated hunks of free space that can simply be assigned
> to the root LV.
> 

vgdisplay

?

It helped me for now, see my other responses to the topic ...

[toc] | [prev] | [next] | [standalone]

#266465

On 1/22/24 10:17, Alain D D Williams wrote:
> On Mon, Jan 22, 2024 at 03:32:30PM +0100, skoric@uns.ac.rs wrote:
>> I am getting the following message at any boot:
>>
>> "The volume "Filesystem root" has only 221.1 MB disk space remaining."
>>
>>   df -h says:
>>
>> Filesystem                  Size  Used Avail Use% Mounted on
>> udev                        1.5G     0  1.5G   0% /dev
>> tmpfs                       297M  9.0M  288M   4% /run
>> /dev/mapper/localhost-root  5.2G  4.7G  211M  96% /
>> /dev/mapper/localhost-usr    14G   12G  948M  93% /usr
>> tmpfs                       1.5G     0  1.5G   0% /dev/shm
>> tmpfs                       5.0M  4.0K  5.0M   1% /run/lock
>> tmpfs                       1.5G     0  1.5G   0% /sys/fs/cgroup
>> /dev/sda1                   228M  133M   84M  62% /boot
>> /dev/mapper/localhost-tmp   2.3G   57K  2.2G   1% /tmp
>> /dev/mapper/localhost-var   2.7G  2.5G   55M  98% /var
>> /dev/mapper/localhost-home  257G   73G  172G  30% /home
>> tmpfs                       297M   40K  297M   1% /run/user/1000
>>
>> As my system has encrypted LVM, I suppose that I shall reduce some space
>> used for /home, and then use it to extend /, /usr, and /var logical
>> partitions. I think I did (or tried to do) something similar several years
>> ago, but forgot the proper procedure. Any link for a good tutorial is
>> welcomed. Thanks.
> 
> The shrinking of /home is the hard part. You MUST first unmount /home, then
> resize the file system, then resize the logical volume.
> 
> umount /home
> 
> Find out how big it is:
> resize2fs /dev/mapper/localhost-home
> 
> Change the filesystem size:
> resize2fs /dev/mapper/localhost-home NEW-SIZE
> 
> Change the partition size:
> lvextend --size 200G /dev/mapper/localhost-home
> 
> The hard bit is working out what NEW-SIZE should be and having it such
> that you use all of the partition but without making the file system size
> greater than the partition size - ie getting the last few megabytes right.
> 
> What I do is make NEW-SIZE 2GB smaller than I want (assuming that it still fits),
> the size I give to lvextend 1GB smaller - so it all works, but there is wasted
> space & it is not quite big enough. I then do:
> 
> lvextend --size +1G --resizefs /dev/mapper/localhost-home
> 
> Ie get lvextend to do the maths & work it out for me.
> 
> Those who are cleverer than me might be able to tell you how to get it right
> first time!
> 
> mount /home
> 
> Extending the others is easy and can be done when the system is running &
> active, something like:
> 
> lvextend --size +1G --resizefs /dev/mapper/localhost-var
> 
> Finally: ensure that you have a good backup of /home before you start.
> 

I use to use LVM and RAID but I quit using that after finding out that 
partition the drive and using gparted was way more easier

[toc] | [prev] | [next] | [standalone]

#266468

On Mon, Jan 22, 2024 at 01:06:16PM -0500, Gremlin wrote:
> I use to use LVM and RAID but I quit using that after finding out that
> partition the drive and using gparted was way more easier

If you allocate all the space during installation and don't leave any
to make adjustments, or to make snapshots, then you're not getting
any of the benefits of LVM.  In this case, you're just doing static
partitioning with extra complexity, and your conclusion would be correct.

The key to LVM is to leave some space unallocated.  Then you get *options*.

[toc] | [prev] | [next] | [standalone]

#266477

On 1/22/24 4:17 PM, Alain D D Williams wrote:
> On Mon, Jan 22, 2024 at 03:32:30PM +0100, skoric@uns.ac.rs wrote:
>> I am getting the following message at any boot:
>>
>> "The volume "Filesystem root" has only 221.1 MB disk space remaining."
>>
>>   df -h says:
>>
>> Filesystem                  Size  Used Avail Use% Mounted on
>> udev                        1.5G     0  1.5G   0% /dev
>> tmpfs                       297M  9.0M  288M   4% /run
>> /dev/mapper/localhost-root  5.2G  4.7G  211M  96% /
>> /dev/mapper/localhost-usr    14G   12G  948M  93% /usr
>> tmpfs                       1.5G     0  1.5G   0% /dev/shm
>> tmpfs                       5.0M  4.0K  5.0M   1% /run/lock
>> tmpfs                       1.5G     0  1.5G   0% /sys/fs/cgroup
>> /dev/sda1                   228M  133M   84M  62% /boot
>> /dev/mapper/localhost-tmp   2.3G   57K  2.2G   1% /tmp
>> /dev/mapper/localhost-var   2.7G  2.5G   55M  98% /var
>> /dev/mapper/localhost-home  257G   73G  172G  30% /home
>> tmpfs                       297M   40K  297M   1% /run/user/1000
>>
>> As my system has encrypted LVM, I suppose that I shall reduce some space
>> used for /home, and then use it to extend /, /usr, and /var logical
>> partitions. I think I did (or tried to do) something similar several years
>> ago, but forgot the proper procedure. Any link for a good tutorial is
>> welcomed. Thanks.
> 
> The shrinking of /home is the hard part. You MUST first unmount /home, then
> resize the file system, then resize the logical volume.
> 
> umount /home
> 
> Find out how big it is:
> resize2fs /dev/mapper/localhost-home
> 
> Change the filesystem size:
> resize2fs /dev/mapper/localhost-home NEW-SIZE
> 
> Change the partition size:
> lvextend --size 200G /dev/mapper/localhost-home
> 
> The hard bit is working out what NEW-SIZE should be and having it such
> that you use all of the partition but without making the file system size
> greater than the partition size - ie getting the last few megabytes right.
> 
> What I do is make NEW-SIZE 2GB smaller than I want (assuming that it still fits),
> the size I give to lvextend 1GB smaller - so it all works, but there is wasted
> space & it is not quite big enough. I then do:
> 
> lvextend --size +1G --resizefs /dev/mapper/localhost-home
> 
> Ie get lvextend to do the maths & work it out for me.
> 
> Those who are cleverer than me might be able to tell you how to get it right
> first time!
> 
> mount /home
> 
> Extending the others is easy and can be done when the system is running &
> active, something like:
> 
> lvextend --size +1G --resizefs /dev/mapper/localhost-var
> 
> Finally: ensure that you have a good backup of /home before you start.
> 

Sounds interesting. Thank you. Will see other opinions too.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web