Configure local storage practice questions

mdadm --add /dev/md0 /dev/sdc

Why it fails: The `--add` option alone does not reduce the existing mirror: it merely attaches /dev/sdc to /dev/md0 as a spare. Since /dev/sdb is still active and healthy, the RAID1 remains in a two-disk configuration, and the new disk will not participate in a rebuild. The old disk must first be explicitly marked as failed and removed so that the array enters a degraded state, allowing `--add` to trigger a recovery onto /dev/sdc.

mdadm --remove /dev/md0 /dev/sdb --add /dev/sdc

Why it fails: Without a preceding `--fail`, the `--remove` command is invalid: mdadm will reject the removal of a fully functional component because that would compromise the mirror's redundancy. Even if `--add` is appended, the kernel's md driver treats the operation as adding a spare rather than rebuilding a replacement. The sequence must start with `--fail` to update the array's state, and the whole compound command should use `--manage` to invoke the proper management interface.

mdadm --replace /dev/md0 --with /dev/sdc

Why it fails: There is no `--replace` operation in the standard mdadm CLI: the tool does not provide a direct 'replace' subcommand or flag. To swap a disk, you must issue a sequence of state changes via `--manage`, specifically `--fail`, then `--remove`, then `--add`. Relying on a nonexistent `--replace` option will simply cause mdadm to exit with an error and leave the array unchanged, so this command is not a valid replacement method.

/etc/fstab: /dev/vg/lv /mnt ext4 noexec 0 0

Why it fails: Missing 'defaults' before noexec; 'noexec' alone is acceptable but typically combined with defaults.

/etc/rc.d/rc.local: mount /dev/vg/lv /mnt -o noexec

Why it fails: Not the standard method; fstab is used for automatic boot mounts.

/etc/rc.local: mount -o noexec /dev/vg/lv /mnt

Why it fails: rc.local is not the standard way; fstab is preferred for boot-time mounts.

df -h

Why it fails: df -h is filesystem-centric: it reads mounted filesystem statistics to report capacity and usage of the underlying block device, but it does not query LVM metadata. An inactive logical volume, or an LV not formatted with a filesystem, will not be shown at all, and even for mounted LVs, the size displayed is the filesystem size, not necessarily the LV size. Therefore it cannot reliably show the current size of a logical volume.

lsblk

Why it fails: lsblk displays the block device tree, including device-mapper names like /dev/mapper/vg-name-lvname and their sizes, but it does so from the kernel's view of block devices, not from LVM's own metadata. It lacks LVM-specific attributes such as LV state, mirror/RAID status, stripes, or the ability to list an inactive LV that has not been activated. Thus it falls short of being a command that directly and fully views logical volume size and attributes.

vgdisplay

Why it fails: vgdisplay is aimed at the volume group layer: it reports total and free physical extent counts, VG size, and the number of LVs and PVs, but it does not break down individual logical volume sizes. You would need to run lvdisplay or lvs to inspect a specific LV's size and properties. Therefore vgdisplay is the wrong tool for viewing the current size of an LV.

pvcreate /dev/sdc; vgcreate vgdata /dev/sdc; lvcreate -L 5G -n lvdata vgdata; mkfs.ext4 /dev/vgdata/lvdata; echo '/dev/vgdata/lvdata /mnt/data ext4 defaults 0 0' >> /etc/fstab

Why it fails: The pvcreate and vgcreate commands are unnecessary and incorrect because vgdata is already present in the system. Running vgcreate vgdata /dev/sdc will fail with a 'volume group already exists' error, and pvcreate on /dev/sdc reinitializes a physical volume that may already be part of vgdata, potentially destroying existing PV metadata or causing LVM to lose track of the VG. Even if those commands succeeded, recreating the volume group is not the requested task; you should simply create the new LV inside the existing vgdata and then format and mount it. The later steps in the option are valid, but the erroneous initial commands prevent the whole sequence from working.

mkfs.ext4 /dev/sdc; lvcreate -L 5G -n lvdata vgdata; mount /dev/vgdata/lvdata /mnt/data; echo '/dev/vgdata/lvdata /mnt/data ext4 defaults 0 0' >> /etc/fstab

Why it fails: The fatal flaw here is running mkfs.ext4 directly on /dev/sdc, the raw physical volume, instead of on the logical volume device. This would format the entire disk as ext4 and overwrite the LVM physical volume metadata, making /dev/sdc unrecognizable to LVM; consequently, the subsequent lvcreate vgdata command would fail because vgdata would no longer have a valid PV backing it. Even if the lvcreate somehow succeeded, the mount command would attempt to mount an LV that was never formatted with a filesystem, and the fstab entry pointing to /dev/vgdata/lvdata would never be valid. The correct order must be LV creation first, then mkfs on the LV, then mounting and adding to fstab.

mdadm --manage /dev/md0 --fail /dev/sdb --remove /dev/sdc

Why it fails: The command uses valid mdadm actions, but it removes /dev/sdc after failing /dev/sdb. That removes the wrong device from /dev/md0 while leaving the failed /dev/sdb still present in the array. If /dev/sdc is healthy and still online, mdadm will refuse to remove it until it has been failed or may remove an active device, risking data loss on that device. The --remove action must always target the exact device that was just marked failed.

mdadm --fail /dev/md0 /dev/sdb; mdadm --remove /dev/md0 /dev/sda

Why it fails: This two-command sequence correctly fails /dev/sdb with the --fail action, but the subsequent --remove command references /dev/sda instead of /dev/sdb. Since /dev/sda was never failed, mdadm will not remove it from the array, and the failed /dev/sdb remains as a faulty spare or active disk. The proper remove step must use the same component device name that was failed, i.e. /dev/sdb, not a different disk.

mdadm --manage /dev/md0 --fault /dev/sdb --remove /dev/sdb

Why it fails: The --fault option is not a valid mdadm action or flag; mdadm expects --fail (or -f) to mark a device as faulty. Because --fault is unrecognized, mdadm aborts with an error and neither fails nor removes /dev/sdb. Even though --manage is a valid prefix, the invalid option prevents the entire command from executing, so this attempt does nothing to the array.

Add /dev/sdb as a physical volume, extend the root volume group, extend the root logical volume, and grow the filesystem. Then move /var/lib/mysql to a new directory on the extended space.

Why it fails: Extending the root volume group and logical volume simply adds free space to the existing root filesystem; it does not create a dedicated mount point for /var/lib/mysql, so database growth can still fill the root volume and affect the entire OS. Moving the database directory to a new folder on the same expanded filesystem provides no isolation, no snapshot capability for MySQL specifically, and does not take advantage of a separate LVM volume that could be managed independently. This approach also fails to address the need to keep the database online during the data migration, as moving directories while MySQL is running can produce an inconsistent copy.

Use lvreduce to shrink the root LV by 10GB, then lvextend to create a new LV for /var/lib/mysql, format with ext4, mount, and copy data.

Why it fails: Shrinking a filesystem with lvreduce is inherently risky and requires the filesystem itself to be reduced before the LV is shrunk; because the root filesystem is typically XFS in RHEL, and XFS cannot be shrunk at all, this command would fail before any space is freed. Additionally, you do not create a new logical volume with lvextend — lvextend grows an existing LV, while the correct command to create one is lvcreate. Using ext4 instead of XFS and shrinking a live root filesystem would also require significant downtime, and the procedure as described never safely copies /var/lib/mysql while the database is running.

Partition /dev/sdb with a single partition, format with ext4, mount at /var/lib/mysql, and copy the data. Then update /etc/fstab.

Why it fails: Partitioning /dev/sdb and formatting it with ext4 yields a plain block device that cannot be resized or managed with LVM snapshots, making it far less flexible than a logical volume and harder to adapt as database storage grows. Mounting the raw partition directly at /var/lib/mysql and then copying data while the database is running risks a corrupted or inconsistent dataset, because the copy is not coordinated with MySQL's flush and the service is not briefly stopped. The option also lacks the temporary /mnt step, so there is no safe window to finalize the switch; an ext4 filesystem on a raw partition works but is not the LVM-based solution expected of an RHEL administrator.

lsblk -f

Why it fails: lsblk -f does not accept a filesystem type filter. It lists every available block device and shows its filesystem details (FSTYPE, LABEL, UUID, and MOUNTPOINT) for all devices, regardless of whether the filesystem is XFS, ext4, swap, or vfat. Because it has no equivalent of blkid's -t option, it would display XFS and non-XFS devices alike, making it incorrect for isolating XFS block devices.

findmnt -t xfs

Why it fails: findmnt -t xfs only displays filesystems that are currently mounted in the system's mount namespace. While it does filter by the XFS type, it reads from /proc/self/mountinfo and thus cannot see block devices that contain an XFS filesystem but are not mounted at that moment, such as an offline disk or an unmounted partition. The question asks for all block devices, not just mounted ones, so this command is incomplete.

df -t xfs

Why it fails: df -t xfs reports disk space usage only for filesystems that are currently mounted, and then restricts that output to those of type XFS with the -t option. It does not probe block devices; instead, it queries the mounted filesystems via statfs and the mount table, so any XFS filesystem that is not mounted will be absent from its output. Therefore it cannot display all block devices with an XFS filesystem, only the mounted subset.

by-path

Why it fails: The /dev/disk/by-path symlink is generated by udev to reflect the physical hardware topology of the device, such as PCI bus, SCSI host, and target ID. Although it is persistent as long as the hardware layout is unchanged, the systemd mount unit or the mount command reading /etc/fstab does not resolve by-path symlinks by default, so it is not a recognized keyword for the file's device field. Consequently, specifying an entry as /dev/disk/by-path/... will not be parsed correctly and is therefore invalid for identifying a filesystem in fstab.

/dev/sda1

Why it fails: Using a raw device name like /dev/sda1 in /etc/fstab is not a valid persistent identification method because kernel-assigned names are allocated at boot time based on detection order, which can change when disks are added, removed, or enumerated differently. This makes the mapping non-deterministic and can cause the system to mount the wrong partition or fail to boot. Static device nodes are also not guaranteed to remain stable across reboots, so they are avoided for critical configuration.

Remove the disk that contains the problematic mount

Why it fails: Incorrect. Removing the disk does not address the misconfiguration in /etc/fstab; the boot failure is caused by the system trying to mount a device that is either missing or incorrectly referenced, not by the disk itself being faulty. Physically detaching or deleting the disk will destroy all data on it and still leave the fstab entry pointing to a nonexistent device, so the failure persists. Recovery requires editing the fstab line, not removing the storage medium.

Boot into single-user mode and run 'mount -a' to list errors

Why it fails: Incorrect. Single-user mode (rescue.target in systemd) is not guaranteed to be reachable because the invalid fstab entry is processed early in the boot sequence and can force the system directly into emergency mode before you can select a runlevel. Even if you do get a shell, running `mount -a` simply re-reads the same damaged fstab and attempts to mount every listed device again, which can hang indefinitely waiting for the missing or invalid device. This command does not list errors for diagnosis; it only retries the same failed operation and cannot fix the underlying fstab problem.

Boot from installation media and reinstall the operating system

Why it fails: Incorrect. Reinstalling the operating system is a drastic and destructive measure that formats the root filesystem, erasing user data, installed packages, and the very /etc/fstab file that needs repair. The boot failure results from one bad line in a text configuration, so a full reinstall is like using a sledgehammer to fix a loose screw. Furthermore, the same installation media provides a rescue mode where you can mount the existing system and edit that single line, making a reinstall both unnecessary and harmful to data preservation.

At the maintenance shell, run 'systemctl emergency' to drop to emergency mode

Why it fails: Incorrect. When you are already at a maintenance shell, the boot process has likely dropped you into emergency mode because the problematic fstab entry caused a mount unit failure; issuing `systemctl emergency` only forces the system into the same emergency target rather than repairing the fstab file. Additionally, emergency mode mounts the root filesystem as read-only, so without first running `mount -o remount,rw /`, you cannot edit /etc/fstab at all. The command merely changes the active target and does not address the root cause, so the system remains unbootable.

ext4

Why it fails: ext4 is incorrect because its maximum single-file size is 16 TiB, which is smaller than XFS's 8 EiB limit, and it lacks online defragmentation. The only way to defragment an ext4 filesystem is offline using e2fsck or the e4defrag tool, which requires unmounting or read-only access, causing downtime. For database workloads that need very large files and continuous availability, ext4's file size ceiling and offline-only defragmentation make it a poor fit.

vfat

Why it fails: vfat is incorrect because the FAT32 variant limits individual files to 4 GiB (2^32 - 1 bytes), which is far too small for any modern database storage. Additionally, it has no journaling, no POSIX permissions, and no support for features like sparse files or reflinks, making it fundamentally unsuitable for a database server. The 4 GiB hard cap alone eliminates it from consideration for large database data files.

swap

Why it fails: swap is incorrect because swap is not a filesystem at all; rather, it is a raw block device or file used by the kernel as virtual memory for paging. A database server stores its files on a real filesystem, and swap cannot hold structured files such as database tables or indexes. Even if a swap file exists on a filesystem, the swap area itself has no filesystem structure and does not provide the file-based storage a database requires.

btrfs

Why it fails: btrfs is incorrect because although it supports very large files (up to 16 EiB) and offers features like snapshots and checksums, it is not yet as commonly used or as battle-tested in enterprise database environments as XFS. Red Hat Enterprise Linux, for instance, has deprecated btrfs in favor of XFS, and its performance under heavy database write loads is often less predictable. Therefore, while technically capable of handling large files, btrfs is not the standard or safest choice for a database server.

mdadm --examine /dev/sda

Why it fails: This command examines the superblock on a component disk, confirming its role and health, but alone it does not show the current array state. It is valid but not the best answer because it lacks the array-level perspective.

cat /proc/mdstat

Why it fails: The /proc/mdstat pseudo-file only exposes the kernel's real-time view of active MD devices, showing sync status and device state. It does not read the on-disk superblock metadata, so it cannot reveal disk member UUIDs, roles, or whether a spare is properly enrolled. As a quick health check it's useful, but for a thorough verification of a RAID 1 mirror's configuration it is insufficient.

mdadm --query /dev/md0

Why it fails: The `mdadm --query` command is intended as a quick device-identification utility, reporting only the basic device type (such as 'is not an md array' or 'is a raid1'), without querying the array's detailed state or the component disks' superblocks. It is not designed to show member disk lists, sync progress, or UUID metadata, which are essential for verifying a mirror's health and configuration. Therefore, while it can confirm that /dev/md0 is a RAID device, it is not suitable for thorough verification.

Both A and B

Why it fails: Combining `mdadm --detail /dev/md0` with `mdadm --examine /dev/sda` is correct because the former validates the assembled array's state, including active member disks and resync status, while the latter independently reads the superblock from the component disk to confirm its array UUID, role, and device identity. This two-level approach verifies both the kernel's array view and the actual metadata stored on the physical disk, providing complete confidence that the mirror is properly configured. It is the standard best-practice verification method for a RAID 1 mirror.

ro,noauto

Why it fails: ro,noauto explicitly prevents boot-time mounting because 'noauto' tells mount -a to skip this entry during system startup, and 'ro' forces the filesystem read-only even if it were manually mounted. Since the requirement is automatic mounting at boot, this combination fails on the core 'auto' criterion, and 'ro' additionally blocks any write activity regardless of file permissions.

noexec,nodev,nosuid

Why it fails: noexec,nodev,nosuid are security hardening options that restrict execution of binaries, ignore device files, and block setuid/setgid bits, but they have no effect on whether the filesystem is mounted at boot. The mount at boot is controlled by the 'auto'/'noauto' option or the lack of 'noauto', not by these restrictions. Therefore, this set does not guarantee automatic mounting and also does not affect root write access.

rw,suid,dev,exec

Why it fails: rw,suid,dev,exec includes the common mount options from 'defaults' but omits 'nouser', meaning any unprivileged user who has the device could mount or unmount the filesystem, a serious security risk. While this set would still be mounted automatically because 'auto' is the default when no 'noauto' is specified, it is not a safe configuration. The missing 'nouser' is the key flaw, as it violates the principle that only root should control system mounts.

auto,root

Why it fails: auto,root is an invalid mount option combination because 'root' is not a recognized mount option in /etc/fstab; valid options include 'auto', 'noauto', 'rw', 'user', and 'nouser'. Although 'auto' would normally trigger boot-time mounting, the invalid 'root' option causes mount to produce an error and reject the entire entry, so the filesystem will not be mounted. This entry would need to be corrected, for example by removing 'root' or replacing it with a valid option.

Filesystem type

Why it fails: Correct. The filesystem type (e.g., ext4, xfs) tells the system how to interpret the device and is required.

UUID

Why it fails: Incorrect. UUID is not a separate field; it is a valid way to specify the device, but the required field is the device identifier itself.

fdisk /dev/sdb (create one partition) -> mkfs.ext4 /dev/sdb (without partition number)

Why it fails: This sequence creates a partition but then formats the entire disk with mkfs.ext4 /dev/sdb instead of /dev/sdb1. The filesystem overwrites the partition table on the disk, effectively erasing the newly-created partition entry and leaving the system unable to mount /dev/sdb1 as expected. Running mkfs.ext4 on a whole disk is also inappropriate for a data disk because it bypasses partitioning and creates a filesystem spanning the entire device, which will collide with the partition metadata. The mount attempt on /dev/sdb1 would then fail because no valid partition exists on disk.

mkfs.ext4 /dev/sdb && mount /dev/sdb /data

Why it fails: Placing a filesystem directly on /dev/sdb without creating a partition table is invalid for a typical data disk in RHEL. While the mount will appear to work, the lack of partitions means the disk cannot accommodate future partitions, and tools such as fdisk or parted will see raw filesystem data instead of a valid MBR/GPT, making management and partition recovery impossible. This non-standard layout is often rejected by server provisioning scripts and can interfere with tools that expect a partitionable block device. The correct approach is to create at least one partition before formatting.

mkfs.ext4 /dev/sdb && mount /dev/sdb /data

Why it fails: Using mkfs.ext4 on the raw block device /dev/sdb and then mounting it by that name is fragile because /dev/sd* names are assigned at boot and can change if device order changes, breaking fstab entries and scripts. Even if the command sequence technically succeeds, a filesystem spanning the whole disk without a partition table offers no place for partition metadata and is not a supported configuration for RHEL systems managing data disks. Strongly prefer creating a partition (e.g., /dev/sdb1) and mounting that; for persistent mounts use /etc/fstab with UUID or /dev/disk/by-id to avoid device-order issues.

The new disk must be partitioned with the same layout as the failed disk.

Why it fails: mdadm works on whole disks or partitions; superblock is used.

The --add command should have been --re-add instead.

Why it fails: --re-add is for reconnecting a temporarily removed disk, not a new one.

The array is still clean and does not need the new disk yet.

Why it fails: If a disk failed, the array is degraded and needs rebuilding.

The thin pool has insufficient free space to accommodate the extension.

Why it fails: If lvextend had been blocked because the thin pool was full, the command would have failed with an error such as 'Insufficient free space in thin pool' and the LV size would not have changed. The fact that the extension succeeded means the pool had sufficient free data blocks to accommodate the new logical size. Therefore, while a full thin pool is a real LVM concern, it is not the reason the filesystem still shows the old size.

The thin volume must be unmounted to extend.

Why it fails: LVM supports growing thin volumes while they are mounted and in use; there is no need to unmount the filesystem. The same is true for most filesystems on RHEL 9, so xfs_growfs or resize2fs can be run online. Unmounting would not cause the extension to appear; without a filesystem resize, even an unmounted and remounted thin volume would still report the old capacity.

He should have used lvextend with the --resizefs option.

Why it fails: The --resizefs option (or -r) is only implemented for regular (thick) logical volumes in LVM, where it can automatically call the appropriate filesystem resize tool. Thin volumes do not support --resizefs; running lvextend --resizefs on a thin volume would be rejected as an invalid option. Instead, the administrator must explicitly invoke xfs_growfs or resize2fs after extending the thin LV.

mkfs.xfs -f /dev/sdb

Why it fails: Forcing a filesystem with mkfs.xfs -f on /dev/sdb writes to the entire raw disk, not to a partition. This bypasses the partition table and can destroy existing partition metadata or adjacent partitions. In Red Hat environments, always create a partition (e.g., /dev/sdb1) and build the filesystem on that partition, not the whole device.

mount /dev/sdb1 /mnt

Why it fails: Attempting `mount /dev/sdb1 /mnt` without `-t xfs` relies on the system to guess the filesystem type, which is risky and often fails when no matching /etc/fstab entry exists. The mount command will read /etc/fstab, find no record for /dev/sdb1, and either error out or try unsafe auto-detection. A correct manual mount must explicitly specify the type with `-t xfs` or a matching fstab entry must exist.

vgcreate myvg /dev/sdb /dev/sdc lvcreate -n data -L 5G myvg mkfs.ext4 /dev/myvg/data mount /dev/myvg/data /data

Why it fails: The volume group myvg is already present in the exhibit, so running vgcreate again is redundant and will fail with an 'already exists' error. Even if it succeeded, using ext4 instead of the RHEL-default XFS is non-standard for logical volumes. Critically, no fstab entry is added, so the mount would not survive a reboot.

lvcreate -n data -L 5G myvg mkfs.xfs /dev/myvg/data mount /dev/myvg/data /data

Why it fails: This sequence formats and mounts the logical volume, but omits the mandatory mkdir /data step — mount will fail because the mount point does not exist. Additionally, without an /etc/fstab entry, the filesystem will not be remounted automatically at boot, so the configuration is not persistent. For a complete configuration, both the mkdir and fstab steps are essential.

pvcreate /dev/sdb vgcreate myvg /dev/sdb lvcreate -n data -L 5G myvg mkfs.xfs /dev/myvg/data mount /dev/myvg/data /data echo '/dev/myvg/data /data ext4 defaults 0 0' >> /etc/fstab

Why it fails: Running pvcreate and vgcreate is unnecessary because the exhibit already defines myvg, and vgcreate will error out when trying to recreate it. More damaging, the fstab entry specifies ext4, but the logical volume was formatted with mkfs.xfs — this mismatch causes mount failures at boot. Even if the filesystem type were corrected, the redundant VG creation shows a misunderstanding of the existing LVM configuration.

Both disks have a valid partition table and can be used directly for RAID.

Why it fails: /dev/sdc has a DOS partition table with a partition, but /dev/sdb has no partition table (GPT but no partitions). For RAID, whole disks can be used without partitions, but the partition tables are not consistent.

/dev/sdb has no partitions and /dev/sdc has a partition; the administrator must remove the partition on /dev/sdc before creating RAID.

Why it fails: While it is possible to use a partition for RAID, for a whole disk RAID it is common to use the whole disk without partitions. However, it is not required to remove the partition; the partition can be used as a RAID member. But the question asks which is true. Option B is not necessarily true.

The administrator can create a RAID 1 array using the whole /dev/sdb and the partition /dev/sdc1 without any changes.

Why it fails: While mdadm can technically use either a whole disk or a partition as a RAID member, mixing them in the same array is poor practice and usually causes size mismatch—the whole /dev/sdb will present its full capacity while /dev/sdc1, as a partition, will be smaller by the partition offset and any reserved space. Because RAID 1 mirrors to the smallest member, the usable capacity would be limited to the partition size, wasting space on /dev/sdb and creating alignment inconsistencies. Additionally, using a whole disk alongside a partition that resides in a DOS partition table can confuse udev and the kernel's md auto-detection, leading to nondeterministic device naming. Therefore, while it might appear to work, it is not a valid or recommended configuration.

The device /dev/sdb has a filesystem on it.

Why it fails: Although pvcreate detects existing filesystem signatures such as ext4 or XFS, it does not hard-fail on them; it issues an interactive warning and prompts whether to overwrite the signature, or can be forced with `--yes`. A filesystem alone is therefore not a reason for initialization to fail outright, and the error in this scenario would have prompted rather than refused.

The device /dev/sdb does not exist.

Why it fails: If /dev/sdb did not exist, the kernel would have no block device node to access, and pvcreate would immediately report `Device /dev/sdb not found` without referencing LVM filtering. Since the administrator is explicitly targeting /dev/sdb, the device node is assumed to be present, and the failure message in the exhibit indicates an LVM-level rejection rather than a missing node.

The device /dev/sdb is already in use by another volume group.

Why it fails: When a device already belongs to a volume group, pvcreate refuses with an explicit message naming that volume group, for example `Physical volume /dev/sdb is still part of a volume group` and instructs you to run `pvremove` first. The error here is a generic initialization failure caused by LVM ignoring the device, not a conflict with an existing PV/VG relationship.