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
