After running 'df -h', the administrator sees that /dev/sda1 is 100% used. 'du -sh /mountpoint' shows only 50% used. What is the most likely cause?
Correct: The file remains on disk until the process releases it.
Why this answer
When a file is deleted but a process still holds an open file descriptor to it, the kernel does not release the disk space until the process closes the file. The 'df' command reports space usage based on the filesystem's superblock, which still counts the deleted file's blocks. 'du' calculates space by traversing the directory tree and summing file sizes, so it does not see the unlinked file. This discrepancy explains why 'df' shows 100% usage while 'du' shows only 50%.
Exam trap
The trap here is that candidates assume 'du' and 'df' should always match, overlooking the fact that 'du' cannot account for space used by unlinked files still held open by processes.
How to eliminate wrong answers
Option A is wrong because bad blocks would cause read/write errors and potential data loss, but they would not create a discrepancy between df and du; bad blocks are marked as unusable and do not inflate used space. Option C is wrong because hard links are counted correctly by both df and du; du counts each hard link's contribution to the directory tree, and df accounts for the inode's allocated blocks only once. Option D is wrong because filesystem corruption typically causes inconsistencies in metadata that fsck can repair, but it would not produce a clean df vs du mismatch; corruption often leads to errors or missing files, not a hidden file consuming space.