Exercise 1: Recommending a Stack for a Long-Term Family Photo/Video NAS — Possible Solution
====================================================================

Recommended stack: Btrfs or ZFS (either integrated filesystem), with
snapshots enabled and, ideally, a mirrored (RAID1-equivalent)
redundancy configuration.

Walking through the framework:

1. Live resizing / flexible allocation -- a nice-to-have here (the NAS
may grow over time as more photos/videos accumulate), but not the
deciding factor.

2. Corruption protection over time -- this is the scenario's own
central requirement. The data is described as "rarely accessed but
never wanted to silently degrade" -- exactly the bit-rot risk profile
the chapter's own backup/archive server scenario was built around:
"backup data can sit untouched for months, and undetected bit rot
could go unnoticed until a restore is actually attempted and fails."
Family photos sitting untouched for years are exposed to the exact
same risk -- a traditional ext4-based stack, per fs1-9, has no layer
anywhere that would ever notice a bit-flip in a years-old photo file,
so the corruption would only be discovered (if ever) at the worst
possible moment, when someone actually tries to view or recover it.

3. Staff familiarity -- for a home NAS, this factor carries much less
weight than it would for a business with existing tooling investment;
a single motivated home user learning one new system (Btrfs or ZFS)
is a reasonable, one-time cost.

4/5. GRUB simplicity and kernel-update stability -- a home NAS is not
typically a strict-uptime production appliance requiring seamless
unattended kernel updates, so ZFS's DKMS friction (fs1-4) is a real
but tolerable cost here, not disqualifying.

6. Snapshots -- genuinely useful for protecting against accidental
deletion of photos, on top of the corruption-detection benefit.

7. Redundancy -- a mirrored configuration (RAID1-equivalent, native to
either Btrfs or ZFS) directly supports self-healing per fs1-3/fs1-4:
if checksumming detects corruption, the good copy from the mirror can
repair it automatically.

Conclusion: since the deciding requirement -- long-term, rarely-
verified data integrity -- maps directly onto Btrfs/ZFS's own central
strength (checksumming and self-healing), and the DKMS/complexity
costs that count against ZFS in a strict-uptime production context
matter much less for a home NAS, either integrated filesystem is a
genuinely well-justified choice here, unlike ws1's own web server
scenario where the same features would have gone unused.

WHY THIS WORKS AS AN ANSWER
------------------------------
This runs the scenario through the framework's own seven questions
explicitly, identifies which one is actually load-bearing for this
specific scenario (corruption over time), and explains why the costs
that count against ZFS elsewhere in the chapter (kernel-update
friction) matter less in this specific context.