Free Practice Questions for the Linux Foundation Certified SYSADMIN LFCS Exam (2026 Updated)

Objective: Configure the Linux NFS (Network File System) server so that two specified client hosts can access the same backup directory with different permissions.

The required configuration is:

NFS client

Required access

Export options

lfcs00098nfs1

Read and write (store backups)

rw,sync,insecure

lfcs00098nfs2

Read-only (restore backups)

ro,sync,insecure

The essential distinction is that the first client must be able to create and modify backup files, while the second client must be restricted to reading existing backup data.

The task explicitly requires the insecure option for both client hosts.

Linux NFS uses /etc/exports to configure which directories are shared, which hosts can access them, and which permissions apply.

Step 1: Connect to the correct Linux server.

The video specifies that this task must be completed on host lfcs00098.

From the candidate terminal, execute:

ssh lfcs00098

This establishes an SSH connection to the designated NFS server.

All NFS export configuration changes must be performed on this server, not on the client hosts.

Step 2: Verify that the NFS server software is installed.

On the Ubuntu environment shown in the video, the NFS server package is normally:

nfs-kernel-server

Check whether the package is installed:

dpkg -l nfs-kernel-server

You can also inspect the service:

systemctl status nfs-kernel-server

If the package is installed and the service is running, continue.

The task is to configure an existing NFS server, so do not reinstall packages unnecessarily.

Step 3: Verify that the backup directory exists.

The task specifies the NFS export directory:

/srv/backup

Execute:

ls -ld /srv/backup

This displays the directory's permissions, owner and group.

For example:

drwxr-xr-x 2 root root 4096 Oct 12 10:00 /srv/backup

The output above is illustrative.

If the directory does not exist, first establish whether the task environment is incomplete. If it is genuinely necessary to create the specified export point, execute:

sudo mkdir -p /srv/backup

Do not modify existing backup files or directory ownership unless needed for authorized client access.

Step 4: Inspect the existing NFS export configuration.

The primary NFS export configuration file is:

/etc/exports

Display its contents:

sudo cat /etc/exports

You can also inspect the configuration using:

sudo nano /etc/exports

The file defines local directories exported to NFS clients.

The general format is:

/directory client1(options) client2(options)

Each client hostname is immediately followed by its own parenthesized options.

There must be no space between the hostname and the opening parenthesis.

This syntax is explicitly documented in the Linux NFS exports(5) manual.

Step 5: Check the currently active NFS exports.

Execute:

sudo exportfs -v

This lists the currently active exports and their effective options.

Check whether /srv/backup is already exported and whether either required client already has an entry.

If an existing configuration is present, modify it carefully rather than creating overlapping or conflicting export entries.

Step 6: Verify that the NFS client hostnames can be resolved.

The task identifies two clients:

lfcs00098nfs1

lfcs00098nfs2

Check name resolution:

getent hosts lfcs00098nfs1

Then:

getent hosts lfcs00098nfs2

These commands query the operating system's configured hostname-resolution services.

Both hostnames should resolve correctly in the exam environment.

Do not replace these hostnames with invented IP addresses.

NFS export configuration supports hostnames, including single hostnames recognized by the system resolver.

Step 7: Back up the existing NFS exports configuration.

Before making changes, execute:

sudo cp -a /etc/exports /etc/exports.bak

This creates a backup copy while preserving file metadata.

It allows recovery if the configuration is accidentally modified incorrectly.

Step 8: Edit the /etc/exports file.

Execute:

sudo nano /etc/exports

Alternatively:

sudo vim /etc/exports

Navigate to the end of the file, or locate the existing export for /srv/backup if one is already present.

Step 9: Configure read/write access for the backup-storage client.

The first requirement is:

First, configure the NFS server to allow access to /srv/backup for host lfcs00098nfs1 to store backups.

The corresponding export configuration is:

/srv/backup lfcs00098nfs1(rw,sync,insecure)

/srv/backup

This is the directory that the NFS server makes available to the specified client.

lfcs00098nfs1

This is the only client identified by this entry.

rw — Read/Write

Allows the NFS client to perform both read and write operations, subject to the underlying filesystem permissions.

This is necessary because the client must store backups.

sync — Synchronous Writes

Makes the NFS server acknowledge write requests only after the relevant changes have been committed to stable storage, as defined by the NFS server's write semantics.

This is appropriate for backup data where durability matters.

insecure — Allow Unprivileged Source Ports

Normally, NFS's secure export behavior requires certain client requests to originate from a privileged port below 1024.

The insecure option relaxes this restriction, permitting requests from unprivileged source ports.

The task explicitly requires this option.

The official NFS manual confirms the behavior of rw, sync and insecure.

Step 10: Configure read-only access for the backup-restore client.

The second requirement is:

Next, configure the NFS server to allow access to /srv/backup for host lfcs00098nfs2 to restore backups only.

The corresponding configuration is:

/srv/backup lfcs00098nfs2(ro,sync,insecure)

lfcs00098nfs2

Specifies the second authorized NFS client.

ro — Read Only

Allows the client to read existing backup files but prevents writes through the NFS export.

This matches the requirement to restore backups only.

sync

Specifies synchronous server behavior. It is safe to include this option even though the export is read-only.

insecure

Allows requests from unprivileged client source ports, as explicitly requested.

The most important difference between the two client definitions is:

lfcs00098nfs1(rw,sync,insecure)

lfcs00098nfs2(ro,sync,insecure)

The second client must not be given rw access.

Step 11: Add the complete NFS export configuration.

The preferred combined entry in /etc/exports is:

/srv/backup lfcs00098nfs1(rw,sync,insecure) lfcs00098nfs2(ro,sync,insecure)

This single line defines the same exported directory with separate permissions for the two clients.

The configuration can also be expressed as two client-specific entries, provided the resulting export table is valid and does not contain conflicting definitions.

Using one line is concise and follows the official exports(5) syntax for multiple clients sharing an export path.

NFS server export table

Step 12: Save the NFS configuration file.

If using Nano, press Ctrl+O, Enter and Ctrl+X.

If using Vim, press Esc, type :wq, and press Enter.

Verify the saved configuration:

sudo cat /etc/exports

The file must contain:

/srv/backup lfcs00098nfs1(rw,sync,insecure) lfcs00098nfs2(ro,sync,insecure)

Preserve any unrelated exports already present on the system.

Step 13: Apply the NFS export configuration.

Execute:

sudo exportfs -ra

exportfs manages the NFS export table.

-r refreshes the export table from the configuration.

-a applies the operation to all configured exports.

This command reloads export definitions without requiring a complete operating system reboot.

For verbose output, you can execute:

sudo exportfs -rav

Ubuntu's official NFS server documentation and the Linux NFS manual describe using exportfs to apply changes made to /etc/exports.

Step 14: Verify the active NFS export configuration.

Execute:

sudo exportfs -v

The output should show /srv/backup exported to both client hosts.

The effective configuration must include the following permissions:

Client

Required effective access

lfcs00098nfs1

rw,insecure

lfcs00098nfs2

ro,insecure

The command may also display other default export options such as root_squash, wdelay, sec=sys, or no_subtree_check, depending on the installed version and configuration.

Their presence does not necessarily indicate an error.

What matters is that the two specified clients have the correct effective access and the required insecure option.

Step 15: Check the NFS server service.

Execute:

sudo systemctl status nfs-kernel-server

The service should report an active operating state.

For a concise check:

systemctl is-active nfs-kernel-server

Expected:

active

If the service is inactive, inspect the logs:

sudo journalctl -u nfs-kernel-server -n 50 --no-pager

If the service is installed and configured correctly but stopped, start it:

sudo systemctl start nfs-kernel-server

There is ordinarily no need to restart a healthy NFS server merely because export rules changed; exportfs -ra is designed to refresh the export table.

Step 16: Verify the backup directory permissions.

Execute:

ls -ld /srv/backup

NFS export permissions and Unix filesystem permissions are separate controls.

Even if lfcs00098nfs1 has an export configured with rw, its application user must also have the necessary filesystem permissions to write to the directory.

Likewise, ro at the export level prevents NFS writes from lfcs00098nfs2, regardless of permissive underlying file permissions.

Do not automatically execute:

sudo chmod 777 /srv/backup

This would unnecessarily grant broad filesystem access.

Also avoid adding:

no_root_squash

unless explicitly required.

The task does not request disabling NFS root squashing, and doing so could expose unnecessary privileges to clients.

Step 17: Verify NFS access from the backup-storage client.

If the client is accessible, connect to:

ssh lfcs00098nfs1

Create a temporary mountpoint:

sudo mkdir -p /mnt/lfcs-backup-test

Mount the NFS export, using the actual NFS server hostname and a protocol version supported by the server:

sudo mount -t nfs lfcs00098:/srv/backup /mnt/lfcs-backup-test

Verify the mount:

findmnt /mnt/lfcs-backup-test

Using a client identity authorized to write to the backup directory, test file creation:

touch /mnt/lfcs-backup-test/lfcs-write-test

If the directory permissions permit this identity to write, the command should succeed.

This tests the read/write access requested for lfcs00098nfs1.

Root access from the client may be mapped to an unprivileged user because of NFS root squashing, so a failure when using root does not automatically mean that the export is configured incorrectly.

Step 18: Verify read-only access from the restore client.

Connect to:

ssh lfcs00098nfs2

Create a mountpoint if necessary:

sudo mkdir -p /mnt/lfcs-backup-test

Mount the export:

sudo mount -t nfs lfcs00098:/srv/backup /mnt/lfcs-backup-test

Verify that backup files can be listed and read:

ls -la /mnt/lfcs-backup-test

Where a readable file is available, open or inspect it using a suitable command.

Next, attempt to create a temporary file:

touch /mnt/lfcs-backup-test/lfcs-readonly-test

This operation must fail because the export is read-only.

An illustrative error is:

Read-only file system

Even if the error wording differs, the important result is that write access is denied by the server.

Step 19: Clean up any test resources.

On the writing client, remove only the temporary verification file you created:

rm -f /mnt/lfcs-backup-test/lfcs-write-test

Unmount the temporary client mount:

sudo umount /mnt/lfcs-backup-test

Repeat the unmount on the other client.

Do not delete or alter actual backup files.

Step 20: Perform final verification on the NFS server.

Reconnect to the NFS server:

ssh lfcs00098

Verify the persistent configuration:

sudo grep '/srv/backup' /etc/exports

Expected:

/srv/backup lfcs00098nfs1(rw,sync,insecure) lfcs00098nfs2(ro,sync,insecure)

Verify the active exports:

sudo exportfs -v

Confirm NFS service health:

systemctl is-active nfs-kernel-server

The final state must satisfy every requirement.

Requirement

Expected result

Exported directory

/srv/backup

Backup-storage client

lfcs00098nfs1

Backup-storage access

Read/write

Backup-restore client

lfcs00098nfs2

Backup-restore access

Read-only

insecure for first client

Present

insecure for second client

Present

Active exports

Correctly refreshed

NFS service

Active

Final Solution

The essential server-side commands are:

# Connect to the NFS server

ssh lfcs00098

# Check the export directory

ls -ld /srv/backup

# Examine existing exports

sudo cat /etc/exports

sudo exportfs -v

# Back up the configuration

sudo cp -a /etc/exports /etc/exports.bak

# Edit the exports file

sudo nano /etc/exports

Add or update the /srv/backup entry to read:

/srv/backup lfcs00098nfs1(rw,sync,insecure) lfcs00098nfs2(ro,sync,insecure)

Save and execute:

# Apply changes

sudo exportfs -ra

# Verify active exports

sudo exportfs -v

# Confirm NFS service status

systemctl is-active nfs-kernel-server

# Verify persistent configuration

sudo grep '/srv/backup' /etc/exports

Technical Verification and References

The solution has been checked against the official Linux NFS manuals and Ubuntu Server documentation.

Linux NFS exports(5) — Defines the export configuration syntax, rw, ro, sync and insecure options.

Ubuntu Server — Network File System (NFS) — Documents the NFS server configuration and export-management procedure.

Linux exportfs(8) — Documents reloading, managing and displaying active exports.

Video verification finding: Task 10 identifies the NFS server lfcs00098 and requires separate access modes for lfcs00098nfs1 and lfcs00098nfs2. The essential answer is the NFS export configuration above. Actual client access must be tested on the relevant systems; correct syntax alone does not establish that network connectivity and filesystem permissions are functioning.

Expected result: The NFS server exports /srv/backup to lfcs00098nfs1 with read/write access and to lfcs00098nfs2 with read-only access. Both client configurations explicitly include insecure, and the settings remain persistent in /etc/exports.

Objective: Identify which Linux block device is experiencing excessive write activity, determine the user process generating that activity, terminate the offending process, and unmount the affected filesystem.

The solution requires four main operations:

Examine block-device read/write statistics.

Identify the process responsible for the heavy disk writes.

Terminate the identified process.

Unmount the filesystem associated with the affected block device.

The video provides useful evidence about the responsible process.

Findings from the video

Required host

lfcs00099

Process generating heavy writes

batches

Observed process ID

891

Process owner

root

Observed write rate Approximately 1,200 KiB/s in one sample

Mountpoint acted on in video

/media/batches

The recording shows batches as the principal writer and the candidate subsequently unmounting /media/batches. However, the original block-device name is not established clearly enough to quote as an exact device path. The solution below includes the commands needed to confirm that mapping.

Step 1: Connect to the correct Linux server.

The video specifies host lfcs00099.

Execute:

ssh lfcs00099

All diagnostic commands, process termination and unmounting must be performed on this host.

Step 2: Examine all available block devices.

Execute:

lsblk

For a more informative output:

lsblk -p -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS

Column

Purpose

NAME

Absolute block-device path

TYPE

Disk, partition, or logical device

SIZE

Device capacity

FSTYPE

Filesystem type

MOUNTPOINTS

Where the device's filesystem is mounted

An illustrative output might be:

NAME TYPE SIZE FSTYPE MOUNTPOINTS

/dev/sda disk 40G

└─/dev/sda1 part 40G ext4 /

/dev/sdb disk 10G

└─/dev/sdb1 part 10G ext4 /media/batches

/dev/sdc disk 20G

└─/dev/sdc1 part 20G ext4 /media/data

This output is an example, not confirmed device assignments from the video.

Do not assume that /dev/sdb1 is the affected device until the actual machine's storage configuration is inspected.

Step 3: Identify the block device experiencing excessive writes.

Use iostat, which is part of the sysstat utilities.

Execute:

iostat -dx 1 5

-d displays block-device activity.

-x enables extended I/O statistics.

1 specifies a one-second sampling interval.

5 requests five reports.

The command displays measurements for each block device.

Pay particular attention to:

Metric

Meaning

w/s

Write requests completed per second

wkB/s

Kilobytes written per second

w_await

Average time spent completing write requests

%util

Percentage of elapsed time during which the device had I/O requests

A device with unusually high sustained write throughput compared with the other devices is a candidate for the problematic storage workload.

An illustrative comparison:

Device r/s w/s rkB/s wkB/s %util

sda 2.00 1.00 8.00 4.00 1.00

sdb 0.00 250.00 0.00 1200.00 95.00

sdc 1.00 4.00 4.00 16.00 3.00

In this example, sdb deserves investigation.

High %util by itself does not establish a device fault, especially on modern parallel-I/O storage. Evaluate write throughput, latency and workload together. The official sysstat documentation defines these metrics.

GitHub

Step 4: Identify which user process is causing the write load.

The recording uses iotop to monitor process-level disk activity.

Execute:

sudo iotop

For a view restricted to processes currently performing I/O:

sudo iotop -oP

-o shows processes actively performing I/O.

-P presents process-level information rather than individual threads.

iotop displays process IDs, owners, disk-read rates, disk-write rates and command names.

The important columns are:

TID PRIO USER DISK READ DISK WRITE COMMAND

The task concerns heavy writes, so focus on DISK WRITE, not DISK READ.

The official iotop manual confirms that these measurements represent process-level I/O activity.

Linux manual page

Step 5: Identify the offending process from the video.

At approximately 32:45–33:25 in the recording, the terminal shows iotop output with processes including:

PID USER DISK READ DISK WRITE COMMAND

891 root 0 B/s ~1200 KiB/s batches

927 root ~1200 KiB/s 0 B/s ingest

909 root ~20 KiB/s ~20 KiB/s data

944 root ~20 KiB/s ~20 KiB/s export

These are rounded observations from the displayed sampling interval, not fixed process characteristics.

The important distinction is that ingest is responsible mainly for read activity in the observed samples, whereas batches is the dominant writer.

Therefore, the process to investigate and terminate is batches, observed as PID 891.

PIDs are assigned dynamically and must be checked on the live system before termination.

Step 6: Verify the identity of the process.

On the exam host, execute:

ps -p 891 -o pid,ppid,user,comm,args

For the recorded session, the command should identify batches if PID 891 is still assigned to the same process.

The ps output displays:

PID: process identifier.

PPID: parent process identifier.

USER: account that owns the process.

COMMAND/ARGS: executable name and command-line arguments.

If the PID is different in a fresh session, substitute the PID obtained from iotop.

Do not terminate PID 891 blindly on another system.

Step 7: Verify the process's actual write activity.

Linux exposes per-process I/O statistics through:

/proc/PID/io

For the observed PID:

sudo cat /proc/891/io

The output includes fields such as:

rchar:

wchar:

syscr:

syscw:

read_bytes:

write_bytes:

cancelled_write_bytes:

The write_bytes field reports bytes attributed to the process as writes to the storage layer.

You can inspect the relevant fields:

sudo grep -E 'read_bytes|write_bytes' /proc/891/io

Take two measurements several seconds apart to determine whether write activity is increasing.

The Linux kernel's /proc/PID/io documentation describes these counters and their limitations.

Linux manual page

Step 8: Identify the filesystem being written to by batches.

Execute:

sudo lsof -p 891

lsof lists open files associated with the selected process.

Look for open files located under the affected mountpoint.

For example, paths might begin with:

/media/batches/

If the process has an open writable file on /media/batches, that supports the connection between the observed write activity and this filesystem.

Be aware that lsof lists open resources; not every open file is necessarily responsible for the observed write rate.

Cross-check with block-device I/O measurements.

Step 9: Identify the actual block device mounted at /media/batches.

Execute:

findmnt --mountpoint /media/batches

For concise output:

findmnt -no SOURCE,FSTYPE,TARGET --mountpoint /media/batches

This displays the filesystem source and mountpoint.

For example:

/dev/sdb1 ext4 /media/batches

If this is the output, the block-device path is /dev/sdb1.

This is illustrative. The actual block device must come from the exam host.

Also verify the mapping through:

lsblk -p -o NAME,TYPE,FSTYPE,MOUNTPOINTS

The official findmnt(8) manual documents using --mountpoint to inspect the filesystem mounted at a particular directory.

Linux manual page

Step 10: Confirm that the identified device is responsible for the heavy write activity.

Compare the block device reported by findmnt with the output of:

iostat -dx 1 5

You should now have both pieces of information required by the first part of the task:

The block device experiencing the heavy writes.

The responsible process.

For the recorded scenario, the process evidence points to batches, and the candidate's selected target is /media/batches.

If the block-device statistics instead identify another device, investigate the discrepancy before terminating anything.

Step 11: Check whether the offending process is still running.

Execute:

ps -p 891

Or, using the PID obtained from the current investigation:

ps -p PID -o pid,user,comm,args

Replace PID with the actual current process ID.

Confirm the command name and owner one final time immediately before sending a termination signal.

Step 12: Terminate the process gracefully.

The recommended first attempt is:

sudo kill -TERM 891

This sends SIGTERM to the observed process.

SIGTERM requests an orderly shutdown and allows applications to perform cleanup operations.

Check whether the process has stopped:

ps -p 891

The official Linux kill(1) manual recommends attempting SIGTERM before SIGKILL when possible.

Linux manual page

Step 13: Forcefully terminate the process only if required.

The candidate in the video uses:

sudo kill -9 891

This sends SIGKILL, which terminates the process without allowing it to handle the signal.

The equivalent named-signal command is:

sudo kill -KILL 891

This is technically valid if the process cannot be stopped normally.

However, it is preferable to attempt SIGTERM first, because abruptly killing a writer may interrupt in-progress writes or application cleanup.

For the recorded process, PID 891 is the primary target. The video additionally shows the candidate killing PIDs 909 and 944, but those processes display much lower write activity. Their termination is not justified solely by the task evidence.

Step 14: Verify the offending process has stopped.

Execute:

ps -p 891 -o pid,comm

If the process has fully exited, it should no longer appear as an active process.

You can also inspect:

sudo iotop -oP

The batches process should no longer be generating disk writes.

If the process has restarted automatically with a new PID, investigate its parent process or service rather than relying on the original PID.

Step 15: Inspect remaining users of the affected filesystem.

Before unmounting, execute:

sudo fuser -vm /media/batches

This identifies processes accessing files on the filesystem.

The options mean:

-v: display verbose information.

-m: identify processes accessing the specified mounted filesystem.

The fuser documentation describes this behavior.

Linux manual page

Review the output.

If unrelated processes still need the filesystem, determine whether they can safely stop accessing it. Do not kill every listed process indiscriminately.

Step 16: Unmount the affected filesystem.

Once the offending process has stopped and the filesystem is no longer busy, execute:

sudo umount /media/batches

This is the unmount operation shown in the recording.

sudo provides administrative privileges.

umount detaches a mounted filesystem from the Linux directory hierarchy.

/media/batches identifies the target mountpoint.

The official umount(8) manual confirms that specifying the mountpoint is the normal way to unmount a filesystem.

Linux manual page

Step 17: Handle a busy filesystem if necessary.

If the command reports:

umount: /media/batches: target is busy

it means the filesystem is still being used.

Recheck:

sudo fuser -vm /media/batches

Also inspect:

sudo lsof +f -- /media/batches

A process may have open files, memory mappings, or its working directory on that filesystem.

Close those references appropriately and retry:

sudo umount /media/batches

Do not immediately force or lazily unmount the filesystem.

A lazy unmount can hide an ongoing problem by detaching the mountpoint while references to the filesystem remain. The official umount documentation warns about this distinction.

Linux manual page

Step 18: Verify the filesystem is unmounted.

Execute:

findmnt --mountpoint /media/batches

A successful unmount should result in no matching mount being displayed.

For an additional check:

mountpoint -q /media/batches

echo $?

A nonzero exit status indicates that the directory is not currently a mountpoint.

Also inspect:

lsblk -p -o NAME,TYPE,FSTYPE,MOUNTPOINTS

The affected filesystem should no longer list /media/batches as an active mountpoint.

Step 19: Verify that the excessive write activity has stopped.

Execute:

iostat -dx 1 5

Compare the affected device's write statistics against the measurements recorded before termination.

Also execute:

sudo iotop -oP

Confirm that the original heavy-writing process is no longer active.

Other normal system processes may continue performing I/O. The requirement is to eliminate the problematic workload and unmount its affected device, not to reduce all system writes to zero.

Step 20: Avoid unnecessary modifications to other devices.

The video shows the candidate issuing additional commands involving /media/data and other processes.

Those actions should not automatically be repeated.

The task asks for the block device under heavy write load and the process causing that load.

Unless measurements establish that several devices are affected, there is no reason to unmount unrelated filesystems.

In particular, do not use:

sudo umount -a

This attempts to unmount multiple filesystems and is inappropriate for a targeted storage operation.

Also do not reformat, repartition or remove the affected block device.

Unmounting does not delete the data stored on the filesystem.

Step 21: Consider whether automatic remounting is configured.

Unmounting /media/batches changes the current mounted state, but it does not necessarily prevent the filesystem from being mounted again after a reboot.

For example, the filesystem may be configured through /etc/fstab or a systemd mount unit.

Inspect relevant configuration if the requirement is specifically to keep the device unmounted across restarts:

findmnt --fstab

However, the task instructs you to unmount the device, not explicitly to remove persistent mount configuration.

Do not alter /etc/fstab or disable unrelated services without a demonstrated requirement.

Step 22: Perform final verification.

Execute:

ps -p 891 -o pid,comm

findmnt --mountpoint /media/batches

lsblk -p -o NAME,TYPE,FSTYPE,MOUNTPOINTS

iostat -dx 1 3

If PID 891 is the same offending process observed in the recording and /media/batches is confirmed as its affected filesystem, the expected result is:

Requirement

Expected result

Correct host

lfcs00099

Heavily written block device

Identified using iostat and lsblk

Responsible process

batches

Observed PID

891

Process owner

root

Process terminated

Yes

Affected mountpoint

/media/batches

Filesystem unmounted

Yes

Original excessive write activity

No longer present

Final Solution

The following is the focused command sequence for the scenario shown in the video.

# Connect to the designated server

ssh lfcs00099

# Inspect block devices and mounted filesystems

lsblk -p -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS

# Identify the device under heavy write load

iostat -dx 1 5

# Identify the process generating disk writes

sudo iotop -oP

# Confirm the process identity

# Video PID 891; verify the live PID before proceeding

ps -p 891 -o pid,ppid,user,comm,args

# Inspect files opened by the process

sudo lsof -p 891

# Confirm the affected block-device mapping

findmnt -no SOURCE,FSTYPE,TARGET \

--mountpoint /media/batches

# Request orderly termination

sudo kill -TERM 891

# Confirm the process stopped

ps -p 891

# Check remaining filesystem users

sudo fuser -vm /media/batches

# Unmount the affected filesystem

sudo umount /media/batches

# Verify the filesystem is no longer mounted

findmnt --mountpoint /media/batches

# Verify block-device mount status

lsblk -p -o NAME,TYPE,FSTYPE,MOUNTPOINTS

# Check write activity again

iostat -dx 1 3

If normal termination fails and the process is still confirmed to be the same offending workload, use:

sudo kill -KILL 891

Then recheck the process state and retry the unmount.

Technical Verification and References

The procedure has been checked against the following upstream Linux and sysstat documentation:

sysstat iostat Manual

— Measuring block-device I/O activity and write throughput.

Linux iotop(8)

— Identifying processes performing heavy disk I/O.

Linux findmnt(8)

— Identifying filesystem sources and mountpoints.

Linux kill(1)

— Terminating processes using signals.

Linux fuser(1)

— Identifying processes using mounted filesystems.

Linux umount(8)

— Safely detaching filesystems.

Video verification findings

At approximately 32:40–34:15, Question 16 appears on host lfcs00099. The recording shows iotop identifying batches (PID 891, owned by root) as the process producing the dominant write activity.

The candidate then runs:

sudo kill -9 891

sudo umount /media/batches

Both commands are technically valid for their respective operations. However, the recording does not provide a sufficiently clear device-to-mountpoint mapping to certify the actual block-device path. It also shows additional process terminations and unmounts that are not established as necessary by the write measurements.

Expected result: The high-write-load block device is identified, the batches process responsible for the excessive writes is terminated, and its associated filesystem at /media/batches is unmounted after confirming the device mapping. Unrelated processes and storage devices remain unaffected.

next last task now please

Worked for 2m 32s