[sf-lug] shrinking filesystem sizes: Re: LVM (& /boot) Re: NEED INFO ABOUT BOOT SECTOR, SPACE LIMITS

Wed Aug 2 19:15:18 PDT 2017

P.S.
Shrinking filesystems is relatively hard.  Most filesystem types
don't support shrinking while mounted (but there are some
exceptions, e.g. tmpfs).  However once a filesystem is
umounted, shrinking the filesystem becomes very doable - for at
least most filesystem types.  Of course if what one wants
to shrink is one's active root filesystem ... yeah, not so
easy - and shrinking partitions can be somewhat problematic -
notably how to reclaim the space after, and if it involves
reshuffling of partition numbers, and Linux kernels don't much
like to reload partition table of a disk that has the disk
or partitions thereupon open (alas, other Unixen can better
and reasonably handle that - as long as one doesn't alter the
partitions or equivalent, that are open/mounted).  But, at least
if I read the documentation properly, there are ways to generally
do that on Linux - if it doesn't alter open disk devices (disks &
partions thereof) ... but looks like a very hairy operation (haven't
yet tried it ... maybe some day ... probably on some scratch
virtual machine or other low risk scenario first, of course).

But with LVM, since volumes can be shrunk, it generally becomes quite
a bit easier.  E.g. I specifically wrote script I relatively regularly
use, which will handle shrinking of ext[23] (and probably ext4) filesystems,
and then shrinking the LV.  In fact it figures out what's the smallest
LV using the VG's PE size, that can contain the smallest the filesytem
can be shrunk to, and shrinks it to that many PEs.  Of course the filesystem
needs to be unmounted, but other than that, pretty much a one
command operation.  I often use it to free space up from
archival/backup filesystems, or others where I can relatively
conveniently unmount them for a bit, and squeeze that otherwise
unused/"wasted" space out of 'em for use for other purposes on the
drive/LVM.

Have a look if one's curious - shrink2fs:
http://www.rawbw.com/~mp/unix/sh/examples/shrink2fs
... okay, it's not changed much from that earlier version, but for
the curious:
$ diff -u <(wget -q -O -  
http://www.rawbw.com/~mp/unix/sh/examples/shrink2fs) <(sudo cat  
~root/bin/shrink2fs)

--- /dev/fd/63  2017-08-02 19:11:07.685068304 -0700
+++ /dev/fd/62  2017-08-02 19:11:07.685068304 -0700
@@ -18,8 +18,9 @@
  outf=
  errf=
  trap '
-       [ -n "$outf" ] && rm -f "$outf"
-       [ -n "$errf" ] && rm -f "$outf"
+       cat "$outf"
+       1>&2 cat "$errf"
+       rm -f "$outf" "$outf"
  ' 0 1 2 3 15
  outf=$(mktemp)
  errf=$(mktemp)
$

> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: LVM (& /boot) Re: NEED INFO ABOUT BOOT SECTOR, SPACE LIMITS
> Date: Wed, 02 Aug 2017 06:51:58 -0700

> LVM is wonderful* :-) (*slightly biased opinion),
> but ... I don't know that *any* of the common boot loaders
> can handle boot filesystem as LVM - though they can certainly
> do root (/) filesystem as LVM, with a separate (non-LVM)
> boot (typically /boot) filesystem.
>
> I think actually most boot loaders are *relatively* restricted
> on what they can handle for boot filesystem - some small to
> fair set of filesystem types (depending upon boot loader, and in
> some cases also what modules are loaded into the boot loader!),
> they can handle md RAID-1 (or md and no RAID at all).
> I think that's about it?  (and maybe some snazzy trickery
> about reading stuff from a file on a filesystem the boot loader
> can deal with, and doing things with the contents of that file -
> e.g. uncompressing it in RAM and mounting it as yet another supported
> filesystem type).
>
> So ... LVM and /boot ... mostly not, as I at least currently
> understand it - at least for /boot itself.  And since /boot
> would be a partition (or close to it, such as md RAID-1, and the
> boot loader just reading what it needs from one of those partitions)
> expanding/growing it is rather non-trivial - as generally there's other
> partition(s) right after it.  I generally advise size of /boot be
> made ample, but not excessive - as growing it later is rather
> annoyingly non-trivial, and if one wants to reclaim space from it
> later, there also isn't particularly good easy way to do that and
> usefully use that space elsewhere.
>
> But also, at least for what I've seen, distributions that use or offer
> to use LVM, generally suck up all remaining space - at least on first
> disk - into LVM.  I think that's relatively wasteful of LVM's
> capabilities ... but alas, it is (dead) simple.
>
> I generally prefer, on first disk, carve out appropriate space
> for /boot (separate partition and filesystem).  The remainder,
> chunk into multiple partitions of equal size ... somewhere between
> 4 and 8 partitions - and give 'em all to LVM.  And *reasonably* but
> not excessively size the remaining filesystems (and swap, if used - do
> swap under LVM - not as partition(s)).  This makes reasonably growing
> things later, if/when/as desired/appropriate, pretty dang easy (at
> least if one hasn't sucked up all of the space on the disk).
> And, if one later has need/reason to use partition(s) for something
> else, so long as one has ample free space, whole partition(s) may
> be "given up" from LVM - to use for whatever other purpose(s) (e.g.
> most all of a whole different operating system or distribution
> ... and use either a common /boot filesystem - or a totally
> separate one - such as on different bootable media).
>
> One can also layer additional stuff under and/or atop LVM,
> as reasonably appropriate and reasonably sane (some orders aren't
> sane), e.g. LUKS (encryption), md RAID, zfs, etc.
>
>> From: "Tom Turner" <seameadowlake at gmail.com>
>> Subject: Re: [sf-lug] NEED INFO ABOUT BOOT SECTOR, SPACE LIMITS
>> Date: Mon, 31 Jul 2017 16:15:04 -0700
>
>> This url might (or might not) provide some relevant information about the
>> "boot partition full" problem.
>>
>> https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1357093
>>
>> The above web-page includes links to other pages reporting the problem.
>>
>> I and thousands of others ran into this problem.  There simply was no way
>> to clear out space, no "remove type" command would work.
>>
>> The cure was to >back up the data, and >re-install Linux, being certain to
>> _not_ choose the LVM option.
>>
>> Another point, I believe that Synaptic is better than apt-get at
>> uninstalling old versions of the kernel. Mr. Texstar, the guru behind
>> PCLinuxOS is adamant that updates should be performed by using Synaptic,
>> not apt-get.
>>
>> More information about the problem, from a post at the above url:
>>
>> Begin quote:
>> "The issue here isn't so much the absolute space initially allocated to the
>> /boot/ LV, it is that the installer allocates 100% of the Volume Groups
>> space.
>>
>> The great advantage of LVM is that space can by dynamically allocated and
>> removed from Logical Volumes as needed.
>>
>> If the installer were to leave 5% of the Volume Group unallocated it would
>> be possible for the system to detect this out-of-space condition and extend
>> the /boot/ LV:
>>
>> lvextend -l 50%FREE VG/boot
>> resize2fs /dev/mapper/VG-boot # assuming ext file-system
>>
>> and at the same time display a prominent warning and options for
>> automatically removing the superseded kernel versions."
>> End quote.
>>
>> Hope this helps. Best regards, Tom
>>
>> On Sun, Jul 30, 2017 at 9:10 PM, Daniel Gimpelevich <
>> daniel at gimpelevich.san-francisco.ca.us> wrote:
>>
>>> On Sun, 2017-07-30 at 19:02 -0700, Mikki wrote:
>>>> Hi, Daniel and all
>>>>
>>>> Excellent question up for which I have no answer.  Here is a copy of the
>>> screenshot of the message, embedded or attached, whichever works.
>>>>
>>>> Mikki
>>>
>>> By the way, the "Examine?" button in your screenshot may yield a few
>>> clues, too.


