CCNA Create and configure file systems Questions — Page 2 of 2

MCQhard

The administrator wants to reduce the file system size to 40GB. Which command sequence should be used?

A.It is not possible to shrink an XFS file system

B.xfs_repair; lvreduce

C.umount /mnt/data; lvreduce -L 40G; mount; xfs_growfs

D.lvreduce -L 40G /dev/vg00/lvol0; xfs_growfs

AnswerA

XFS does not support shrinking. To reduce size, you must back up, recreate the LV and file system with the desired size, and restore.

Why this answer

XFS is a high-performance 64-bit journaling file system that does not support online or offline shrinking. Once an XFS file system is created, its size cannot be reduced; the only way to reclaim space is to back up the data, destroy the file system, recreate it at the desired size, and restore the data. Therefore, any attempt to shrink an XFS file system using lvreduce or similar tools will corrupt the file system.

Exam trap

Red Hat often tests the misconception that any file system can be shrunk using logical volume management tools like lvreduce, but XFS is a notable exception that requires full data migration to reduce its size.

How to eliminate wrong answers

Option A is correct because XFS does not support shrinking. Option B is wrong because xfs_repair is used to repair an XFS file system, not to prepare it for shrinking, and lvreduce would shrink the logical volume without shrinking the XFS file system, causing corruption. Option C is wrong because unmounting and using lvreduce to shrink the logical volume still attempts to shrink an XFS file system, which is impossible; the subsequent mount and xfs_growfs would only grow the file system, not fix the corruption.

Option D is wrong because lvreduce -L 40G shrinks the logical volume without shrinking the XFS file system, and xfs_growfs is used to expand an XFS file system, not to shrink it; this sequence would corrupt the file system.

Practice this question →

MCQeasy

A Red Hat Enterprise Linux system has a second disk /dev/sdb with a single partition /dev/sdb1 that was formatted as XFS and mounted at /mnt/backup. The administrator wants to change the filesystem on /dev/sdb1 to ext4 without losing existing data. Which steps should be taken in order?

A.Unmount, mkfs.ext4 /dev/sdb1, then mount

B.Use xfs_admin to change type

C.Use fsck.ext4 to convert in place

D.Backup data, unmount, mkfs.ext4, remount, restore data

AnswerD

Preserves data by backing up and restoring after reformat.

Why this answer

Option D is correct because you cannot convert an XFS filesystem to ext4 in place; the only safe method is to back up the data, unmount the partition, create a new ext4 filesystem with mkfs.ext4, remount, and then restore the data. XFS and ext4 have fundamentally different on-disk structures (e.g., allocation groups vs. block groups, different journaling formats), so no in-place conversion tool exists.

Exam trap

The trap here is that candidates assume a filesystem can be 'converted' in place using a command like fsck or a tuning tool, when in fact only a backup-and-restore cycle is safe for changing between fundamentally different filesystem types like XFS and ext4.

How to eliminate wrong answers

Option A is wrong because running mkfs.ext4 on a partition that currently contains an XFS filesystem will overwrite the existing filesystem metadata, destroying all data without any conversion. Option B is wrong because xfs_admin is a tool for tuning XFS filesystem parameters (e.g., changing the UUID or label), not for changing the filesystem type to ext4. Option C is wrong because fsck.ext4 is a filesystem check and repair tool for ext4; it cannot convert an XFS filesystem to ext4, and attempting to run it on an XFS partition would fail or cause corruption.

Practice this question →

MCQeasy

Refer to the exhibit. The administrator wants to create a single file system that spans the entire 20 GB disk /dev/sdb. All data on the disk can be discarded. Which steps are required to create an XFS file system on the whole disk?

A.Run mkfs.xfs /dev/sdb directly; it will overwrite the partition table and create a file system.

B.Use pvcreate /dev/sdb, then vgcreate, lvcreate, and format the logical volume with mkfs.xfs.

C.Run mkfs.xfs -f /dev/sdb; it will force creation of XFS on the whole disk without partition table.

D.Use fdisk to delete all partitions, create a new partition spanning the whole disk, then run mkfs.xfs on the new partition.

AnswerD

Correct procedure: remove partitions, create single partition, format with XFS.

Why this answer

Option D is correct because creating a file system directly on a whole block device (like /dev/sdb) without a partition table is not recommended and may cause issues with system tools and boot loaders. The proper procedure is to first create a single partition spanning the entire disk using fdisk (or parted), then format that partition (e.g., /dev/sdb1) with mkfs.xfs. This ensures a valid partition table is present, which is expected by most Linux utilities and the kernel.

Exam trap

Red Hat often tests the misconception that mkfs can be run directly on a whole disk (e.g., /dev/sdb) without a partition table, leading candidates to choose options A or C, but the correct Red Hat practice is to always create a partition first.

How to eliminate wrong answers

Option A is wrong because mkfs.xfs /dev/sdb will attempt to create a file system on the raw disk without a partition table, which is not a standard practice and can confuse tools like blkid or the kernel; it does not 'overwrite' the partition table in a safe or expected way. Option B is wrong because LVM (pvcreate, vgcreate, lvcreate) is unnecessary for a single disk spanning the entire space; it adds complexity and requires additional steps, and the question asks for a file system on the whole disk, not a logical volume. Option C is wrong because mkfs.xfs -f /dev/sdb forces creation on the raw disk, but still lacks a partition table; the -f flag only overwrites an existing file system, not the requirement for a partition table.

Practice this question →

MCQmedium

An administrator needs to create a new 500MB swap partition on a disk that already has an extended partition. The disk /dev/sda has partitions: /dev/sda1 (primary, /boot), /dev/sda2 (extended), /dev/sda5 (logical, swap, 2GB). The administrator wants to add another swap partition, but fdisk shows no free space. Which approach should be used?

A.Use LVM to create a logical volume for swap

B.Use a file-based swap file

C.Shrink the filesystem on /dev/sda1 to create free space

D.Delete /dev/sda5 and recreate it with larger size

AnswerB

Swap files can be created on a mounted filesystem without repartitioning.

Why this answer

Option B is correct because the disk has no free space (the extended partition consumes all remaining space after /dev/sda1, and logical partitions are contained within it). Adding a swap file is the simplest and safest approach: it does not require repartitioning, works with any filesystem, and is fully supported by systemd and swapon. The administrator can create a 500MB file, format it as swap with mkswap, and enable it with swapon.

Exam trap

The trap here is that candidates assume a new partition must be created, overlooking that swap files are a fully supported and simpler alternative when no free partition space exists.

How to eliminate wrong answers

Option A is wrong because the scenario does not mention LVM being in use; converting a non-LVM disk to LVM would require significant reconfiguration and is not the simplest solution. Option C is wrong because shrinking /dev/sda1 (a primary partition containing /boot) would not create free space outside the extended partition; the extended partition already occupies all remaining space, so any freed space would still be inside the extended partition and would require complex partition table manipulation. Option D is wrong because deleting /dev/sda5 and recreating it larger would still be limited by the size of the extended partition; it does not add a second swap partition, and it would destroy the existing swap without solving the need for additional swap space.

Practice this question →

MCQmedium

A logical volume /dev/vg_data/lv_data formatted as XFS is full. The administrator extends the LV by 1 GB using 'lvextend -L +1G /dev/vg_data/lv_data'. Which additional command is required to use the new space?

A.xfs_repair /dev/vg_data/lv_data

B.xfs_growfs /mount/point

C.resize2fs /mount/point

D.lvresize -L +1G /dev/vg_data/lv_data

AnswerB

Correct: Grows the XFS filesystem to use the extended LV.

Why this answer

After extending the logical volume, the XFS file system must be grown to recognize the new space. The `xfs_growfs` command resizes an XFS file system to fill the available space in the underlying block device, and it requires the mount point as an argument (not the device). This is necessary because XFS does not support online resizing via a simple block device extension; the file system must be explicitly told to expand.

Exam trap

The trap here is that candidates confuse the file system type and apply the wrong resize command (e.g., `resize2fs` for ext4) or think that extending the logical volume automatically grows the file system, which is not true for XFS.

How to eliminate wrong answers

Option A is wrong because `xfs_repair` is used to check and repair XFS file system corruption, not to resize it; running it on a healthy file system would be unnecessary and could cause downtime. Option C is wrong because `resize2fs` is the tool for ext2/ext3/ext4 file systems, not XFS; using it on an XFS file system would fail or cause damage. Option D is wrong because `lvresize` is the command to resize the logical volume itself, which has already been done with `lvextend`; repeating it would either do nothing or attempt to extend again, but it does not resize the file system.

Practice this question →