Lab: produce a storage and maintenance report

Prepare a small fixture

Use a regular account in the Linux machine. Run the following in one Bash session and continue only if directory creation succeeds:

study_storage_dir=$(mktemp -d /tmp/learnwithsk-storage.XXXXXX)
printf '%s\n' "$study_storage_dir"

Record the path. Create only a few tiny files:

printf 'first observation\n' > "$study_storage_dir/one.txt"
printf 'second observation\n' > "$study_storage_dir/two.txt"
findmnt --target "$study_storage_dir" -o SOURCE,TARGET,FSTYPE,OPTIONS
df -h "$study_storage_dir"
df -i "$study_storage_dir"
du -sh "$study_storage_dir"

Explain why two small files may occupy more allocated storage than their text length. Do not fill the disk or exhaust inodes to demonstrate the concept.

Interpret the tiny fixture

Run wc -c "$study_storage_dir/one.txt" "$study_storage_dir/two.txt" to count content bytes. Compare those values with du -sh, which reports filesystem allocation rounded for display. Allocation units and directory metadata explain why tiny text can consume more than its character count. Do not expect df -h to visibly change after two files; its display precision and the filesystem's other activity can hide such a small difference.

Your table should have separate columns for target path, mount source, filesystem type, available space, and inode information. If /tmp is memory-backed, say so: the fixture's observed filesystem is not automatically the same as the site's later home-directory filesystem.

For a worked diagnosis, imagine df -h has room while df -i is exhausted on the target filesystem. The next investigation is file counts and the workload creating small entries, not deletion of the largest unrelated file. If neither counter is exhausted, inspect the exact error and relevant mount/quota limits rather than manufacturing an exhaustion result.

Write two distinct diagnosis plans

For a byte-capacity alert, identify the actual mount and the owning workload before inspecting large directories. For an inode alert, investigate many small files on that same filesystem. Mark these as proposed diagnosis plans unless you actually observe either condition.

Inspect lsblk and determine whether the environment exposes an ordinary guest disk layout. OrbStack's shared storage architecture is not a substitute for a full VM with an attached disposable disk for partitioning or LVM creation. Include that limit in the report.

On Ubuntu, inspect the installed and candidate version of bash and run the simulated targeted upgrade from the package bite. This lab previews only; the virtualization module contains the actual controlled patching exercise.

Cleanup and checkpoint

rm -- "$study_storage_dir/one.txt" "$study_storage_dir/two.txt"
rmdir -- "$study_storage_dir"

Record the mount, bytes/inodes observation, package candidate, and proposed next step. Explain why deleting arbitrary logs, formatting a device, or running a broad container prune would not follow from this evidence.

Revision: inspect the target path, distinguish constraints, preview maintenance, remove only fixtures. The completed exercise is a report, not a claim that you resolved a real disk-full incident.

Sources

Primary references: findmnt↗; APT simulation↗.