CCNA Create and configure file systems Questions

df displays information about mounted filesystems, including total size, used space, available space, and the mount point, by reading filesystem statistics via statfs(2). This makes it the standard command for checking how full a mounted filesystem is. Unlike du, it does not walk the directory tree; it queries the filesystem itself.

XFS is the correct default filesystem in RHEL 8. Since RHEL 7, XFS has been the default choice, and it continues in RHEL 8 due to its scalability for large storage systems, metadata journaling, and support for online, non-destructive growth. Anaconda, the RHEL installer, preselects XFS for the root filesystem on new installations unless an administrator explicitly changes it.

This is the correct setting. A dump value of 0 is the standard choice on modern Linux systems, as dump(8) is obsolete and almost never used. The pass value of 1 tells fsck(8) to check this filesystem at boot, and 1 is specifically used for the root filesystem; other filesystems use pass=2 to run after the root check completes.

XFS project quotas are designed to limit usage of a directory subtree by assigning a project ID (e.g., project 42) to /data and setting a hard block limit. All files in /data, including the database files, inherit that project ID, and when the aggregate usage reaches the limit, further writes return the 'Disk quota exceeded' (EDQUOT) error. This is exactly the behavior described in the question, making it the correct explanation.

fsck is the generic filesystem check front-end that probes the filesystem type on /dev/sdc1 and invokes the appropriate underlying tool, such as e2fsck for ext4. The -n option forces it to answer 'no' to every repair prompt, making the run strictly read-only and non-destructive. This lets the administrator see errors without changing anything, exactly what a dry-run check needs.

Running mount with no arguments displays the kernel's current mount table, typically sourced from /proc/mounts, in a format showing the device, mount point, filesystem type, and mount options (e.g., /dev/sda1 on / type xfs (rw,relatime)). This output is precisely a list of all currently mounted filesystems, including real devices, pseudo-filesystems like sysfs, and bind mounts. As the standard command for mounting and unmounting filesystems, its bare invocation serves as the canonical way to view the complete active mount configuration.

Mounting a filesystem with nosuid disables the setuid and setgid bits on all executable files within it, so a binary cannot temporarily assume the UID or GID of its file owner. This is critical for partitions like /tmp that are writable by unprivileged users, because a setuid root binary created there could otherwise be exploited for privilege escalation. Administrators commonly include nosuid when mounting removable media or network shares to prevent untrusted binaries from attaining local higher privileges.

mkfs.xfs is the XFS-specific formatting utility provided by the xfsprogs package. Running it against /dev/sdb1 initializes the partition with an XFS superblock, allocation-group headers, and the associated metadata structures. It is the canonical, unambiguous command for creating an XFS filesystem, which makes it a correct answer.

xfs_growfs works by expanding the filesystem's data allocation structures to consume the additional space that must already exist on the backing device. Before running the command, the administrator must have extended the partition or logical volume using lvextend or a partition editor. When invoked on a mounted XFS filesystem with no arguments, it grows the filesystem to the maximum size permitted by the underlying block device.

The swapon command activates an existing swap device. After a partition has been prepared with mkswap, it is not automatically enabled; running swapon /dev/sdd1 makes the kernel immediately use that partition as paging space. Without this step, the swap space remains available only as a prepared but inactive signature on disk.

xfs_growfs is the proper command to expand an XFS filesystem online, and it can be run while the filesystem is mounted. Passing the mount point /var/log instructs the tool to grow the filesystem to consume all available space in the underlying logical volume after an lvextend operation. This command performs the growth without requiring a reboot or unmounting, making it the correct and immediate solution for a full /var/log partition.

Switching the /etc/fstab entry to use the filesystem's UUID (e.g., UUID=abc-123) makes the mount independent of the kernel's device node naming order, because the UUID is burned into the filesystem superblock and remains constant regardless of which /dev/sdX node the disk acquires. After editing the file, running 'mount -a' mounts all entries listed in /etc/fstab that are not already mounted, applying the new configuration immediately without needing a reboot. This is the standard, reliable way to handle devices whose /dev names are not stable.

The UUID deadbeef-cafe-babe-0000-000000000000 is the correct answer because the exhibit's fstab excerpt shows this exact UUID in the line that contains the 'swap' keyword in the options field. This UUID is the device identifier that the system uses to find and activate swap space at boot time, either via swapon or through systemd's fstab generator. In modern Linux, swap devices are reliably referenced by UUID to avoid ambiguity if disk device names change.

Uppercase -L is the mkfs.xfs option for setting the XFS volume label, and `data` becomes that label on /dev/nvme0n1p1. This creates a filesystem that can later be referenced via `-L data` in mount options or by symlinks under /dev/disk/by-label/. The command is correct as written and satisfies the requirement to create a labeled XFS filesystem.

This is correct. XFS is not repairable by fsck; fsck only inspects the XFS log to see whether the filesystem was cleanly unmounted and reports a 'clean' status based on that flag alone, without traversing metadata structures. To actually verify and repair an XFS filesystem you must use the dedicated xfs_repair utility, so a read-only XFS filesystem after a crash would still be reported as 'clean' by fsck while remaining unusable for writes.

ext4 filesystems can only be shrunk while unmounted; the resize2fs tool does not support online shrink. Therefore, to free space from an ext4 LV, the filesystem must be unmounted, shrunk, and then the LV reduced, meaning the operation cannot occur while the volume is in use.

lvextend -L +2G extends the logical volume by 2 GiB, giving the underlying block device more capacity, and resize2fs then grows the ext4 filesystem online to occupy the newly available space. When invoked without a size argument, resize2fs expands the filesystem to fill the entire LV, and ext4 permits this while the filesystem is mounted, so no unmount is needed.

blkid /dev/sda1 is correct because blkid is a util-linux command that scans the specified block device and prints its detected attributes, including the filesystem UUID, along with the filesystem type and partition label. It reads the superblock directly via libblkid, so the device does not need to be mounted. This is the standard tool for looking up a filesystem's UUID in a scriptable, field-friendly format.

Although blkid shows a UUID and type, the superblock error indicates the filesystem is not valid. This can happen if the partition was created but not formatted, yet blkid might show leftover metadata. Typically, you must run mkfs.xfs to create the filesystem.

lsblk -o UUID /dev/sda1 is correct because lsblk enumerates block devices and can output any column you request, including UUID. This works without mounting the filesystem and is a direct, efficient way to list the UUID for a specific device like /dev/sda1.

The error explicitly states the mount point is missing, so the NFS export path is irrelevant until the local directory exists. Creating /mnt/nfs with mkdir -p satisfies the mount point requirement, after which mount -a will succeed provided the server is reachable and the export is permitted.

XFS's on-disk structures, particularly its multiple allocation groups and B-tree-based extent maps, allow concurrent allocations and reads/writes to different file regions without a single global lock. This makes XFS scale nearly linearly with CPU count and mixed parallel workloads, which is exactly what a database server with many concurrent sessions demands. The allocation group design is the key reason XFS outperforms ext4 on parallel I/O patterns.

When the partition on /dev/sdb1 is smaller than 1 GiB, mkfs.xfs automatically uses 1024-byte blocks instead of the usual 4096-byte blocks. This tuning improves space efficiency on small volumes by reducing the overhead associated with larger blocks, such as internal fragmentation and per-block metadata structures. The administrator did not need to specify any option; this is the default behavior for sub-1 GiB XFS filesystems.

XFS is the correct choice because it is the default filesystem on RHEL 9, and Red Hat fully supports it for production workloads. While XFS itself does not have native snapshot capabilities, it works seamlessly with LVM, which provides snapshot functionality for consistent backups and recovery. Its allocation groups, scalable inode handling, and high concurrency support make it ideal for large database files, exactly what the administrator needs.

install -d /mnt/newmount is correct because it creates the directory /mnt/newmount, and unlike plain mkdir, it also creates any missing parent components. Even though install is often used to copy files and set modes, with the -d option it acts purely as a directory-creation utility. Because the command succeeds and the result is a real directory, it satisfies the requirement.

This sequence correctly creates an XFS filesystem on the existing /dev/sdb1, assigns it the label 'backup' using xfs_admin -L, and mounts it by label with 'mount -L backup /mnt/backup'. Mounting by label resolves through /dev/disk/by-label, avoiding dependence on unstable device names, and works without needing an /etc/fstab entry for immediate use. It assumes the partition already exists and that /mnt/backup is a valid mount point, both of which are prerequisites.

blkid reads the filesystem metadata on a block device and prints the UUID, TYPE, and LABEL directly from the superblock; it does not require the device to be mounted or an entry in /etc/fstab. Running blkid /dev/sdb1 is the correct first step to capture the exact UUID to place in an fstab line, ensuring the mount uses a stable identifier rather than a transient device node.

This is the correct sequence for expanding an XFS filesystem on an LVM logical volume: lvextend first allocates the additional disk space by extending the logical volume, and then xfs_growfs /data expands the filesystem to fill the newly available space. XFS can only be grown while mounted, and specifying the mount point /data tells the tool exactly which filesystem to target. Running commands in this order ensures no space is wasted and the filesystem remains consistent throughout the operation.

The /tmp mount point is the correct answer because the exhibit explicitly shows it as an ext4 filesystem mounted with the noexec option. This mount flag instructs the Linux kernel to refuse execve() calls for files located on that filesystem, preventing binaries from being launched directly from the world-writable /tmp directory. No other mount point listed in the exhibit displays the noexec flag, making /tmp the only matching option.

Alter the /etc/fstab entry for /dev/sdb1 to include exec (or remove noexec), then run mount -o remount /mnt/data to re-read the options without a full unmount. This tells the kernel that the filesystem is allowed to serve as a source of executable programs. Using fstab ensures the change survives a reboot, and the remount applies it immediately to the mounted filesystem.

This is the correct sequence because it creates an XFS filesystem on the intended /dev/sdb1, creates the /data mount point, immediately mounts the device with the mount command, and appends a persistent fstab entry using the xfs type. The && chain stops if any step fails, preventing a broken configuration. XFS is the default and supported filesystem for RHEL/CentOS 8+ and supports extended attributes.

lvresize is the general-purpose LVM command for altering a logical volume's size, and it can both increase and decrease the volume equally well. When reducing an LV, you specify a smaller size (absolute, by extent count, or as a percentage), and it will adjust the LV accordingly, optionally resizing the underlying filesystem with the -r/--resizefs flag if the filesystem supports it. Because it handles both directions, it is one of the two valid commands for shrinking an LV.

The exhibit shows /dev/sdc as a whole disk with no recognized partitions (e.g., no /dev/sdc1). Before you can format and mount storage, you must create a partition table and a partition on the disk using a tool such as parted or fdisk. This step creates the necessary block device /dev/sdc1, which can then be formatted with mkfs.xfs and mounted. Without a partition, neither the device name referenced in the question nor a filesystem exists.

This is the correct procedure: lvextend -L +10G first expands the LV by 10 GiB, making additional physical extents available to the LV. Then resize2fs grows the ext4 filesystem to fill the enlarged block device, either online or offline, without unmounting. Because both commands operate in place and preserve the existing data, this safely completes the extension.

The correct sequence starts with `pvmove /dev/sdb`, which relocates every allocated physical extent on that disk to any available free extent elsewhere in the same volume group (vg01). Once the source PV is completely empty, `vgreduce vg01 /dev/sdb` safely removes it from the volume group's metadata, allowing the disk to be repurposed or detached without risking data loss or LVM corruption.

Editing /etc/fstab to add noexec to the /boot entry updates the persistent source of truth for that filesystem's options. Running mount -o remount /boot then asks the kernel to reapply the mount flags from fstab without requiring an unmount, so the new noexec setting takes effect while the system stays running. This is the correct way to change mount options permanently and immediately.

This command creates a new XFS filesystem on /dev/sdb1 and assigns the volume label 'data' in a single step using the uppercase -L option. The -L flag is the correct way to set a label during XFS creation, unlike the lowercase -l which configures the log. This exactly matches the requirement to create an XFS filesystem with the specified label, so it is the correct answer.

This is the correct procedure for enabling user quotas on XFS. Adding uquota to the mount options in /etc/fstab ensures the option persists across reboots, and remounting applies it to the live filesystem. The xfs_quota command in expert mode (-x) with the -c option runs a quota command non-interactively; 'limit -u' sets the user's block soft and hard limits, with suffixes like 'm' and 'g' for megabytes and gigabytes. This is the standard, supported method for XFS quota enforcement.

`lsof +L1 /uploads` enumerates open files whose link count is zero — exactly the deleted-but-still-in-use files that are consuming space. Once identified, you can either close the file gracefully (e.g., by restarting the application) or terminate the offending process, causing the kernel to drop the last reference and free the inode's blocks. This is the targeted, surgical remedy: it doesn't touch valid uploads and it directly releases the missing space. After the process is killed, the directory will show no trace of the file, but df will report the reclaimed capacity.

The exhibit shows VG vg00 has no free physical extents, so you cannot create a new logical volume in that volume group without first adding capacity. Adding /dev/sdc as a physical volume via pvcreate or vgextend expands the VG's available space, after which a new logical volume can be created with lvcreate and then formatted with a filesystem such as xfs using mkfs.xfs. This is the standard approach when a dedicated disk is available and the goal is to allocate a new filesystem from an existing volume group.

Correct: for an NFS mount in /etc/fstab, the nfs filesystem type is used and the options nosuid,hard provide the required security and reliability. nosuid disables setuid bit processing on the remote filesystem, and hard ensures client processes hang and retry if the server goes down, avoiding premature I/O errors. This entry is the only one that satisfies both requirements without conflicting options.

The logical volume /dev/vg_data/lv_web is not activated at boot because the volume group vg_data is not set to auto-activate. In RHEL, LVM auto-activation is controlled by the volume_list setting in /etc/lvm/lvm.conf or by the LVM systemd units; if vg_data is excluded, the /dev/mapper/vg_data-lv_web device node is not created at boot, so /etc/fstab's mount attempt fails with a 'special device does not exist' error. Running vgchange -ay vg_data or enabling auto-activation would make the mount succeed. This precisely matches the symptom in the exhibit, so this is the correct answer.

This is the correct two-step sequence: first mkswap /dev/sdc1 writes the swap signature (version 2 header with UUID and page count) onto the partition, making it a valid swap area. Then swapon /dev/sdc1 reads that signature, validates it, and registers the device with the kernel's swap subsystem, adding it to the active swap list visible under /proc/swaps. This immediately enables kernel memory paging to the device without requiring a mount point. The order is mandatory because swapon will reject a device that does not already contain a valid swap header.

The -o loop option is what makes this command correct. Without an explicit filesystem type, mount probes the file and detects the ISO 9660 filesystem automatically. The kernel associates the regular file /tmp/rhel.iso with an available loop device (e.g., /dev/loop0), then mounts that device at /mnt/iso. This is the standard, minimal way to mount an ISO file.

xfs_growfs is the standard tool for resizing an XFS filesystem, and running it with a mount point grows the filesystem to occupy all available space in the underlying device or logical volume. This command works online—meaning the filesystem can remain mounted and in use during the operation—which is a key advantage in production environments. Therefore, xfs_growfs /mnt is a valid and correct answer for resizing an XFS filesystem.

xfs_growfs requires the target XFS filesystem to be mounted because it performs an online growth operation, reading the current geometry via the mounted filesystem and updating the superblock without unmounting. The lvs attributes for lvol1 lack the 'o' flag (open), which indicates that the logical volume is not currently open/mounted. Since xfs_growfs is invoked on a device that is not mounted, it cannot determine the filesystem's mountpoint and returns an error indicating the filesystem is not mounted. Mounting the LV first and then re-running xfs_growfs with the mountpoint or device would resolve the issue.

The scenario explicitly states that /mydata does not exist, and systemd requires the mount point directory to be present before mounting any filesystem defined in /etc/fstab. For each fstab entry, systemd generates a mount unit that will fail if the target directory is absent, reporting an error like "mount: mount point /mydata does not exist." Because this directory is missing, the mount unit for /mydata fails, causing the boot to enter emergency mode. The solution is to create the directory with mkdir -p /mydata and then run mount -a to verify.

Use 'sfdisk' to clone the partition table from /dev/sda to /dev/sdb, ensuring the new disk has a matching partition layout with the correct RAID partition type and UUIDs. After that, 'mdadm --manage /dev/md0 --add /dev/sdb1' enrolls the freshly partitioned partition as a spare, causing the array to start rebuilding the mirror data. This sequence properly introduces the new disk into the existing RAID1 without disrupting the active array.

This is the only complete sequence: mkfs -t ext4 /dev/sdb1 (equivalent to mkfs.ext4) creates a fresh ext4 filesystem, mkdir /data provides the required directory mount point, mount /dev/sdb1 /data attaches the filesystem for immediate use, and appending a correctly formatted fstab line ('/dev/sdb1 /data ext4 defaults 0 0') ensures the filesystem is mounted automatically at boot. The fstab line contains the six required fields in the correct order, making this the correct answer.

This is the primary command that carves out a logical volume named lv_data from the existing volume group vg_data with a size of 10 GiB. The -L flag specifies the size and -n assigns the name, making this an essential step in creating the LV device node under /dev/vg_data/. Without this command, no logical volume would exist to format or mount.

The -b option in mkfs.ext4 sets the filesystem block size in bytes, overriding the default of 4096 bytes. With -b 1024, the filesystem uses 1 KiB blocks, which reduces internal fragmentation for volumes that will hold many small files, though it also reduces the maximum supported filesystem size. This is the correct syntax for creating a valid ext4 filesystem with a non-default block size.

The safe sequence is to first shrink the filesystem with resize2fs so its data structures fit within a smaller block device, then use lvreduce to shrink the logical volume to match (or slightly exceed) the new filesystem size, ensuring no filesystem metadata is truncated. After that, the freed extents become available in the volume group, allowing lvextend to grow lv_share without any data loss. This ordering is mandatory because the kernel/filesystem must be told about a smaller size before the underlying block device is reduced.

/etc/fstab is the filesystem table that the system reads at boot to determine which filesystems must be mounted, where, and with what options. It contains fields for the device or UUID, mount point, filesystem type, mount options, dump flag, and fsck pass order. Both the mount command and systemd's fstab generator use this file to create mount units, making it the definitive configuration for automatic mount-at-boot behavior on a Linux system.

xfs_growfs is an online resizing tool that operates on a mounted XFS filesystem; it takes the mount point as its argument and uses the live filesystem's geometry to determine the new size. If the filesystem is not mounted, xfs_growfs cannot obtain the necessary superblock and allocation group information via the kernel, so the operation fails. This requirement is the exact opposite of the old ext2/3/4 resize2fs workflow, which typically requires unmounting, and is a key differentiator for XFS administration.

The filesystem UUID is a unique identifier generated at mkfs time and stored in the filesystem superblock. It remains constant even if the disk moves to a different port or the device name changes. Using UUID= in /etc/fstab ensures the correct filesystem is mounted at boot. This is the standard, reliable method for persistent mount configuration.

mkswap initializes a disk partition or file by writing a swap signature and labeling information, preparing it for use as virtual memory. Without this step, the kernel does not recognize the device as swap, so mkswap is a mandatory prerequisite for any swap area. It is a distinct operation separate from filesystem creation, because swap uses a raw layout rather than a filesystem.

pvresize re-reads the size of an existing physical volume and grows its metadata so that newly available sectors at the end of the device become usable physical extents. Because /dev/sdc is already a PV in vg_app, this is the correct single step to reclaim the unused 80 GB. After pvresize, vg_app gains free extents that can be assigned to lv_home with lvextend.

The `grpquota` mount option instructs the kernel to enable per-group quota accounting and enforcement on an ext4 filesystem. When placed in `/etc/fstab` or passed via `mount -o remount,grpquota`, the kernel tracks block and inode usage by group ID and can enforce limits when the `quotaon` utility activates them. This option is used alongside `usrquota` when both user and group limits are required, but it is equally valid by itself.

lsblk -f /dev/sdb1 is correct because the -f (--fs) option makes lsblk output the filesystem type, label, UUID, and mount point for the specified block device. It reads this information from udev and kernel device da, which ultimately come from the filesystem superblock, so it works whether the device is mounted or not. This makes it ideal for verifying that /dev/sdb1 was formatted with the expected filesystem before attempting to mount it.

df -h — Correct: this command invokes df with human-readable units and reports actual disk space usage per mounted filesystem. It shows total capacity, used space, available space, and use percentage, which is exactly what you need to determine if a slow file server is hitting a full partition. Since full filesystems are a top cause of write performance degradation, df -h is the right first diagnostic.

The -s option is the correct way to set the physical extent size for a new volume group. In vgcreate -s 16M vg_data /dev/sdc1, the 16M argument defines each physical extent as 16 MiB, so all subsequent logical volumes are allocated in 16 MiB chunks. This ensures that new logical volumes align with the company policy of 16M extents from the moment the VG is created.

This is the correct sequence: the lvextend -L +50G /dev/vg00/lvol0 command first extends the logical volume by 50GB, giving the underlying block device more space; then xfs_growfs /data online-grows the mounted XFS filesystem to fill the expanded LV. XFS can only grow, not shrink, and growth must happen after the LV is enlarged, not before. Because xfs_growfs defaults to using all available space, no size argument is required after extending the LV.

Extending the logical volume then growing the XFS filesystem online satisfies the no-unmount constraint, since XFS supports live growth via xfs_growfs on a mounted filesystem. The lvextend command adds 5 GB from the volume group, immediately increasing available space on the root filesystem.

Without a filesystem, the partition is just raw block storage; the kernel cannot mount it because there is no superblock or inode structure to manage files. Running mkfs.xfs writes the XFS superblock, allocation groups, and journaling structures onto /dev/sdb1, making it a valid, mountable filesystem. This step is mandatory after partitioning and before attempting any mount operation.

mkfs.ext4 /dev/sdb1 is correct because mkfs.ext4 is a front-end to mke2fs -t ext4, which initializes a fresh ext4 filesystem on the partition. It writes the essential on-disk metadata—superblock, descriptor blocks, inode table, and journal—so the partition can be mounted and used by the Linux kernel. This is the standard command a junior administrator would run after a partition like /dev/sdb1 has been created.

This is the complete and correct procedure: fdisk creates a 1 GB partition on /dev/sdd (assigned as /dev/sdd1), mkswap writes the swap signature to that partition, swapon activates the swap for immediate use, and adding the line to /etc/fstab ensures automatic activation at boot. The fstab entry alone or the swapon alone would be incomplete, but combining them covers both current-session and persistent swap. The fdisk step also ensures the partition actually exists with the desired size, unlike the other options that assume a preexisting /dev/sdd1.

blkid is the dedicated utility that enumerates all block devices visible to the system and prints each file system's UUID, TYPE, LABEL, PARTUUID, and other attributes by default. Since it scans every block device under /dev via libblkid, a bare `blkid` command displays the UUIDs of all file systems without needing a device argument or a filesystem-specific tool.

In vgdisplay, the Free PE count is 5115 and the PE size is 4.00 MiB, so the unallocated capacity equals 5115 × 4 = 20,460 MiB. Converting MiB to GiB by dividing by 1024 yields 19.98 GiB, which is the available free space. This is the exact value that vgdisplay reports as the remaining space in the volume group.

XFS file systems are designed to be grow-only. The on-disk structures, especially the B+tree metadata and dynamic inode allocation, do not support in-place shrinkage, and there is neither an xfs_shrink command nor an option in xfs_growfs to reduce the size. To reduce the size, you must back up the data with tools such as xfsdump, destroy or remove the logical volume, recreate it at the desired size, create a new XFS file system, and restore the data. Attempting to shrink a live XFS file system with any tool is unsupported and will lead to corruption.

The correct procedure is to first copy all data from /dev/sdb1 to a safe location (e.g., tar, rsync, or cp to another disk), then unmount the partition, run mkfs.ext4 /dev/sdb1 to create a new ext4 filesystem, remount the partition, and finally restore the data from the backup. This sequence preserves user files and directory structure because the destructive mkfs operation is performed only after a verified backup exists, and the restore repopulates the freshly formatted ext4 filesystem with the original content.

A file-based swap file is the correct choice here because it can be created on any existing mounted filesystem without repartitioning the disk. You create a file (e.g., with fallocate or dd), then format it with mkswap and activate it with swapon, optionally adding an entry to /etc/fstab for persistence. This completely avoids the disk-space constraints and partition-table limitations that block the other options, making it the only immediately viable method to add 500MB of swap.

xfs_growfs is the intended command to expand an XFS filesystem to fill the newly available space in the underlying logical volume. It operates on a mounted filesystem and uses the VFS layer to increase data and inode block counts without offline downtime. The command's argument is the mount point (or device) and it extends the filesystem to the LV's current size. Because XFS can only grow (not shrink), this is the single missing step after the LV has already been enlarged.