Exercise 2: Reversing the Shrink Order — Possible Solution
====================================================================

What goes wrong:

Per the chapter's own warn-box, "shrinking must always go filesystem
first, then logical volume... Reducing the logical volume before the
filesystem has been shrunk to fit truncates the space out from under
data the filesystem still believes it owns, corrupting it." Running
lvreduce first shrinks the underlying block device immediately --
the logical volume now physically has less space than it did a moment
ago. But the filesystem sitting on top of it (per the chapter's own
model, the filesystem is a separate layer built on top of the logical
volume) still has its own internal metadata describing a filesystem
of the ORIGINAL, larger size -- it still believes blocks exist at
locations that, after lvreduce, may no longer be part of the volume
at all.

If any of the filesystem's own data or metadata happened to be stored
in the region that got cut off by the premature lvreduce, that data
is now simply gone -- not corrupted-but-recoverable, but physically no
longer part of the device the filesystem lives on. Even data that
wasn't in the cut-off region can end up in an inconsistent state,
since the filesystem's own internal bookkeeping (e.g. free space maps,
inode tables) was built assuming the larger size that no longer
exists.

Correct order:

The filesystem must be shrunk first, to a target size that will
comfortably fit within the SMALLER logical volume size being planned
-- for ext4, this means running resize2fs to that smaller target size
while the filesystem still has its full original space available to
safely reorganize its own data into the smaller footprint. Only after
resize2fs has successfully completed and the filesystem itself now
fits within the intended smaller size should lvreduce be run to
actually shrink the logical volume to match. This way the logical
volume is never made smaller than what the filesystem currently
occupies.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the actual mechanism of the corruption (the filesystem's
own metadata references space that no longer physically exists after
a premature lvreduce) rather than just restating "wrong order = bad,"
and gives the specific correct order the chapter itself specifies.