[sf-lug] (re)partitioning (Re: LVM ? :-))

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] LVM ?  :-)
> Date: Wed, 11 Nov 2015 23:49:18 -0800

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> ...but repartitioning is quite inconvenient and generally requires a
>> reboot if it's where the operating system is running or the data is
>> otherwise being used.
>
> Tiny quibble -- and I'm almost ashamed to post it (except it's gentle
> revenge for your own tiny quibbles ;->  ), but:   In the general case,
> repartitioning because you need to move data around to destroy some
> partitions and change sizes doesn't _quite_ necessitate a reboot, only
> going to runlevel 1 long enough to do maintenance.  Which amounts to
> going offline, naturally.
>
> If you have to do this shuffle more than once a decade on average for a
> system, I'd say you're doing something very wrong, so personally I think
> LVM's gosh-wow factor of being able to do this transparently, because of
> an extra indirection layer, comes at too high a price in complexity and
> increased likelihood of system-endangering sysadmin error.
>
> But hey, suit yourself.

Ah, good catch, right you are - I was skipping over some relevant
details.

I rather miss the "bad old days", in some ways, of most Unix
implementations in the day of old.  Where they'd let one do pretty much
any repartitioning (or the equivalent), pretty much without
restriction.  "Of course" if one did something stupid - like shrink or
move start, or change the number of an existing partition, all bets
were off - at least if it was at all a partition that was still in
use/open - but otherwise one could quite freely muck about with
changing of partitions.  The operating system presumed he/she doing
such knew what they were doing, and it would do as it was told, however
(un)wise such an operation may be.

Linux has generally taken a different approach on that, notwithstanding
newer kernels.  It wouldn't let one change partitioning on a disk if
*anything* was open on the disk.  Highly inconvenient.  Or, a bit more
precisely, one could make the change to disk itself, but the kernel
wouldn't pick up the change, and would continue to use the prior
partitioning ... at least until a reboot or such.

Newer Linux kernels do allow the kernel to have its idea of how the
disk is partitioned changed dynamically (with perhaps some slight
exceptions?).  However I've yet to see any partitioning software that
integrates that functionality - at least all I've noticed do the same
old way, and ask the kernel to reread and reload the whole partition
table from the disk, and, still the old way, the kernel refuses if
anything on the disk is active (open).  However the kernel has
mechanisms to inform it about partition changes (specifically telling
it, partition-by-partition) - but I've yet to see partitioning software
take advantage of that.

It *should* be the case that any changes to partitions that don't
change the start, number of partition, and don't shrink, should be fine
even if the partition is in use.  And everything else should be fine
for partitions not in use, even on the same disk, notwithstanding the
aforementioned restrictions of any partitions on same disk that are in
use.  But again, haven't seen that integrated into partitioning
software - perhaps there's some I'm not aware of that does that?

And single user mode ... run level 1, or s (or S) ... - well, still
can't change start of or shrink root (/) partition while that's in use,
nor change its number, at least while it's in use on the disk, and
similar may apply to /usr filesystem for separate /usr and
distributions/installations requiring /usr for single user mode (e.g.
systemd as init), but yes, you are quite correct, other than that,
dropped down to single user mode, can make all those other changes
without requiring a *reboot*.  And ... with pivot_root, might even be
possible to even redo the root (/) filesystem on disk ... provided
one's active root (/) filesystem is elsewhere when that's being done.

Shuffle more than once a decade?  Oh, varies by installations.  I find
in practice, for most, there's almost never a need to change
partitioning after the initial installation ... perhaps with some
changes to partitioning right around time of installation itself or
completion thereof.  But some other systems I find partitioning changes
end up being "needed" a bit more often ... but still fairly rarely -
like maybe not more frequently than about once every 3 to 5 years or
more ... notwithstanding some relatively easy trivial changes that can
be done safely and conveniently live (changing partition type, but
nothing else).  E.g. my personal laptop, which I muck about with quite
a bit ... pretty darn rare I change partitioning - exception being on
relatively rare occasion I might change the type of an existing
partition ... but that's about it - everything else is done at "higher"
layers - e.g. LUKS, LVM, swap, ZFS, filesystems, etc.  Only bit I think
I change more frequently, is sometimes with Virtual Machines (VMs) ...
may quite muck about with those more - often shoehorning them into
relatively tight configurations and ... sometimes needing to "stretch"
them a bit ... or reclaim some space they don't actually need to
repurpose for something else.  "Of course", with typical
hot-add/hot-remove capabilities of VMs, and also often LVM or similar,
often much of that shuffling is done "live", without ever taking the VM
down.  And of course too, some of it with VMs, is done with "throw
away" / test installations - just to test out, determine actual
(relatively minimal) sizes needed (prototyping, etc.), mucking about
with partitions/LVM because some distribution's install won't let one
do a better configuration directly at initial install, etc.  But
notwithstanding those exceptions, don't change partitioning very often.