Courseiva
Storage ManagementhardMultiple ChoiceObjective-mapped

LFCS Storage Management Practice Question

You are a Linux administrator at a mid-sized company. The company runs a critical PostgreSQL database on a server running CentOS 7. The database stores its data on a 500GB logical volume (lv_pgdata) in volume group vg_pg. The filesystem is XFS. Recently, the database team reports that write performance is degrading, and the disk is nearly full (95% usage). You have added a new 200GB SSD to the server, and you need to increase the storage capacity and improve write performance for the database. The database can tolerate a brief downtime (less than 5 minutes) for maintenance. You want to use LVM to add the new SSD as a physical volume, extend the volume group, and then extend the logical volume and filesystem. Additionally, you want to improve write performance by placing the frequently written database transaction log on a separate faster storage. However, the database configuration expects the transaction log to be in a subdirectory of the data directory. You have the following options: A. Create a new logical volume for the transaction log, format it as XFS, mount it on the data directory's subdirectory, and move the log files. B. Add the SSD as a PV, extend vg_pg, extend lv_pgdata, and then use LVM's pvmove to move all extents to the SSD. C. Add the SSD as a PV, create a new VG, create a new LV for the transaction log, format as ext4, mount, and reconfigure the database. D. Use LVM's striping (RAID 0) across the existing HDD and new SSD to improve performance, then extend the filesystem. Which option best meets the requirements of increasing capacity and improving write performance with minimal downtime?

⚠ Common exam trap

Many candidates confuse 'improving performance' with 'moving all data to the SSD' (Option B) or 'striping across devices' (Option C), failing to recognize that isolating the write-intensive transaction log onto the faster SSD is a more targeted and effective performance optimization that also preserves the existing capacity increase.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Add the SSD as a PV, extend vg_pg, extend lv_pgdata and resize the filesystem for capacity. Then create a new LV on the SSD, format as XFS, mount it on the transaction log subdirectory, move the log files, and update the database configuration to point to the new location.

It directly addresses both requirements: increasing capacity by extending the existing logical volume and filesystem using the new SSD as a PV, and improving write performance by isolating the database transaction log onto the faster SSD via a separate LV mounted on the expected subdirectory. This approach minimizes downtime (under 5 minutes) by performing the resize and mount operations quickly, and it respects the database's configuration expectation that the transaction log resides in a subdirectory of the data directory.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Add the SSD as a PV, extend vg_pg, extend lv_pgdata and resize the filesystem for capacity. Then create a new LV on the SSD, format as XFS, mount it on the transaction log subdirectory, move the log files, and update the database configuration to point to the new location.

    Why this is correct

    This increases capacity and isolates log writes to SSD, improving performance with minimal downtime.

  • Add the SSD as a PV, extend vg_pg, extend lv_pgdata and resize the filesystem for capacity. Then use pvmove to move all data to the SSD, leaving the HDD unused.

    Why it's wrong here

    This does not increase capacity (still 500GB) and wastes the HDD.

  • Use LVM's striping (RAID 0) across the existing HDD and new SSD to improve performance, then extend the filesystem.

    Why it's wrong here

    Striping increases risk of data loss if either disk fails, and requires data migration.

  • Add the SSD as a PV, create a new VG and LV for the transaction log, format as ext4, mount, and reconfigure the database to use the new location.

    Why it's wrong here

    Creating a separate VG is unnecessary and ext4 may not be optimal for database logs.

Quick reference

RAID Level Comparison

RAID LevelMin DisksFault ToleranceReadWriteUsable Capacity
RAID 02NoneExcellentExcellent100%
RAID 121 diskGoodModerate50%
RAID 531 diskGoodModerate67–94%
RAID 642 disksGoodLower50–88%
RAID 1041 disk per mirrorExcellentGood50%

RAID is not a backup strategy — it protects against disk failure but not against accidental deletion, ransomware, or site-level events.

About these practice questions

This LFCS question is part of Courseiva's 507-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This LFCS practice question is part of Courseiva's free Linux Foundation certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LFCS exam.