Create and configure file systems practice questions

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

Why wrong: The command creates the ext4 filesystem but then attempts to mount it to /data without first creating that directory — mount(8) will fail with 'mount point /data does not exist'. Even if the directory existed, this sequence omits the /etc/fstab entry entirely, so the filesystem would not be mounted after a reboot. Persistence requires an fstab record, not just an immediate mount.

mkfs -t ext4 /dev/sdb1 && echo '/dev/sdb1 /data ext4 defaults 0 0' >> /etc/fstab && mount /data

Why wrong: This sequence writes the fstab entry before verifying that the mount point exists and then issues mount /data with no device argument, which relies on fstab lookup but fails because /data is absent. Creating a filesystem and adding an fstab line for a nonexistent directory is invalid; the mount attempt would report that /data does not exist. The missing mkdir prevents both the immediate mount and any future boot-time mount from succeeding.

mkfs.ext4 /dev/sdb1 && mkdir /data && mount /dev/sdb1 /data && blkid /dev/sdb1 >> /etc/fstab

Why wrong: Running blkid /dev/sdb1 outputs key=value data such as /dev/sdb1: UUID="..." TYPE="ext4", which is not a valid /etc/fstab line — fstab requires whitespace-separated fields: device (or UUID=), mount point, filesystem type, options, dump, and pass. Appending this raw output corrupts fstab and would cause mount -a to fail with a parsing error. The correct way to reference a filesystem by UUID in fstab is a line like UUID=... /data ext4 defaults 0 0.

df -i

Why wrong: df -i — Incorrect: -i switches the report to inode counts rather than block usage, showing used and free inodes on each filesystem. Inode exhaustion is a real failure mode, but it produces 'no space left on device' errors while block space remains; it does not reflect the free data blocks that govern write performance. A server with plenty of free inodes can still have a completely full disk, so this gives no useful signal about slow write throughput.

du -h --max-depth=1 /

Why wrong: du -h --max-depth=1 / — Incorrect: du sums the sizes of files and directories under the given path, so this shows how much space the root directory's immediate children consume, not how full the underlying filesystem is. By default du can cross mount points, meaning it mixes together usage from multiple partitions and misses the free-space report that df provides. Even if it reports directory sizes, it never shows available capacity or use percentage per filesystem.

du -sh /

Why wrong: du -sh / — Incorrect: du -sh / simply gives the cumulative apparent size of the entire root path in human-readable form, rolling all mounted filesystems into one number. It does not break down usage per partition, does not report free space, and does not indicate which filesystem's capacity might be throttling writes. Unlike df, du also counts files being written but not yet synced differently, so it is not a reliable indicator of actual on-disk availability.

The directory /mnt/backup is not empty.

Why wrong: A non-empty directory never blocks a mount operation; the Linux kernel will happily mount a filesystem over existing contents, hiding them until the filesystem is unmounted. The mount(8) utility does not check whether the mountpoint contains files, so the technician would see no error at all if this were the only issue. Therefore, a non-empty /mnt/backup would not explain a mount failure.

The device /dev/sdc1 does not exist.

Why wrong: If /dev/sdc1 were missing, the mount command would fail with an explicit error like 'mount: /dev/sdc1: can't read superblock' or 'no such device' because the device node or underlying device does not exist. This type of error points directly to the device, not to the mountpoint's security context. Since the error is device-specific, it would not be confused with a SELinux or directory-related denial.

The filesystem on /dev/sdc1 is not XFS.

Why wrong: If the filesystem on /dev/sdc1 were not XFS, mount would identify the mismatch after reading the superblock and return an error such as 'mount: /dev/sdc1: wrong fs type, bad option, bad superblock'. That message is recognizably about the filesystem type, not about the mountpoint's context or the device node's existence. Because the operation would fail before any SELinux mountpoint check, this cause is distinct from the correct answer.

Run 'mdadm --manage /dev/md0 --add /dev/sdb'

Why wrong: The mdadm mirror is composed of partitions, not raw disks, so adding /dev/sdb as a whole disk would make it a non-conforming member and fail to integrate with /dev/sda1. You must first partition /dev/sdb with an identical layout (e.g., using sfdisk) and then add /dev/sdb1 to the array. Without a proper partition entry of type 'fd' (Linux RAID autodetect) or matching UUID, mdadm will reject the device.

Remove the failed disk with 'mdadm /dev/md0 --fail /dev/sdb1' then add new.

Why wrong: Since the original /dev/sdb1 is already marked as failed and removed from the array, executing '--fail' again is redundant and may even return an error. The recovery procedure should skip straight to copying the partition table from the surviving disk and then using '--add' to enroll the new /dev/sdb1. Failing a device that is no longer active does not help rebuild the mirror; it only wastes time.

Run 'mdadm --assemble --scan' to rebuild the array automatically.

Why wrong: 'mdadm --assemble --scan' only activates an existing array by reading superblocks from member disks; it cannot restore a failed disk or trigger a rebuild. If the array is already running (as implied by the failure of one mirror member), assembly is not needed at all. This command would not partition the new disk, and it would simply return the current array to active state without replacing the missing member.

mount -t nfs -o ro,root_squash nfs.example.com:/exports/app /mnt/app

Why wrong: This option is wrong because root_squash explicitly enables the NFS default behavior in which the server maps the client root user (UID 0) to an unprivileged anonymous account such as nfsnobody. The task specifically calls for no_root_squash, so this command does the opposite of the required squash setting and would cause client-root operations to be attributed to nobody instead of root. Although the ro flag is correct, the squash policy makes this mount fail the requirement.

mount -t nfs -o ro,no_root_squash,nosuid nfs.example.com:/exports/app /mnt/app

Why wrong: This command adds nosuid, which disables setuid and setgid bit execution on the mounted filesystem. While nosuid is a legitimate hardening option and would not prevent the mount from working, it is an extra flag not specified in the requirement; the task asks for exactly ro and no_root_squash, and adding an unrequested mount option changes the mount's behavior. Therefore, in the context of this exam question, this variant is incorrect even though nosuid itself is not harmful.

mount -t nfs -o rw,no_root_squash nfs.example.com:/exports/app /mnt/app

Why wrong: This option is wrong because it uses rw instead of ro, making the NFS share writable from the client. With rw, the client can create, delete, or modify files on /exports/app, which directly contradicts the requirement to mount the share read-only. Even though no_root_squash is correctly present, the rw flag is a fatal deviation, so the entire command must be rejected.

mkfs.xfs -l data /dev/nvme0n1p1

Why wrong: The lowercase -l option in mkfs.xfs is reserved for log configuration suboptions (e.g., logdev=..., size=...), not for naming the filesystem. Supplying `data` as its argument is syntactically invalid and will be rejected; even if parsed, it would attempt to set log parameters rather than the volume label. Only uppercase -L assigns the label, so this command fails to produce a filesystem labeled `data`.

mkfs.xfs -f /dev/nvme0n1p1

Why wrong: The -f flag forces mkfs.xfs to overwrite any existing filesystem signature on the partition, which is useful when re-creating a filesystem. However, it controls neither the label nor any naming parameter: the resulting XFS volume will have no label unless an explicit label option (like -L) is given. Because the question requires a labeled filesystem, this command is incomplete.

mkfs.xfs -n data /dev/nvme0n1p1

Why wrong: The -n option configures XFS naming/version parameters such as ftype, not the filesystem label. In this context `data` is not a valid naming setup, and the option is only used to tune features like the version of the naming protocol or ftype values. Therefore the command would error out or set an unintended naming feature, not label the volume, making it wrong.

e2label /dev/sda1

Why wrong: e2label /dev/sda1 is a filesystem utility specifically for ext2/ext3/ext4 volume labels; it reads or sets the label stored in the superblock, not the UUID. The UUID is a separate 128-bit identifier in the same superblock, and e2label has no option to display it.

findmnt /dev/sda1

Why wrong: findmnt /dev/sda1 prints the mount relationship and defaults to columns like SOURCE, FSTYPE, MOUNTPOINT, and OPTIONS. It does not include UUID by default; you would have to explicitly add -o UUID, and even then it is a mount-aware wrapper, not the primary tool for querying raw device identifiers.

file -s /dev/sda1

Why wrong: file -s /dev/sda1 inspects the raw data on the device and identifies the filesystem type (for example, 'Linux rev 1.0 ext4 filesystem data'), but it is not designed to extract or display a UUID. Its purpose is file type magic detection, not filesystem attribute lookup.

suid

Why wrong: suid is not a valid mount option for /etc/fstab because the corresponding option is nosuid (to disable setuid bit). Specifying suid would enable setuid, but it is not commonly used in fstab; instead, nosuid is the standard option.

nodev

Why wrong: nodev is technically a valid mount option that prevents the kernel from interpreting block or character device nodes on the mounted filesystem, which is a useful security hardening measure. In this particular question, however, it is not one of the three options that make up the correct answer set—noexec, noatime, and relatime are the intended choices. The exam is testing your ability to identify the exact set of correct mount options from the list, so even though nodev is a legitimate flag, selecting it here would be marked wrong.

touch /mnt/newmount

Why wrong: touch /mnt/newmount is wrong because touch's purpose is to update file timestamps or create an empty regular file. After running it, /mnt/newmount would be a zero-length regular file, not a directory, so any subsequent attempt to cd into it or create files under it would fail. Thus it does not create a directory as requested.

ln -s /mnt /mnt/newmount

Why wrong: ln -s /mnt /mnt/newmount creates a symbolic link named /mnt/newmount that points to the /mnt directory. The resulting filesystem entry is a symlink (file type l), not a newly created directory; it merely references the existing /mnt directory. Because the question asks to create a new directory, and this command only creates a pointer, it is not a correct choice.

ln /mnt /mnt/newmount

Why wrong: ln /mnt /mnt/newmount attempts to create a hard link named /mnt/newmount pointing to the same inode as /mnt, but Linux forbids hard links to directories to prevent filesystem cycles. The kernel returns an error such as 'Operation not permitted', so no directory is created. Even if it were allowed, a hard link is not the same as creating a new directory — it is just an additional name for the same directory, making this command incorrect.

The mount point is incorrect.

Why wrong: If the mount point were incorrect, df would show either a different filesystem or no entry at all for this logical volume. The LV is mounted at the correct path, so df is indeed showing the filesystem on that LV, but it reports the filesystem's size, not the block device's size. Since the filesystem was not grown after lvextend, the old capacity persists even though the underlying device has been enlarged.

The physical volume is full.

Why wrong: The physical volume is not full; the volume group still has roughly 250G of free space (VFree), and lvextend completed successfully. If the PV were truly full, lvextend would have failed, leaving the LV at its original size, in which case df would report that unchanged size and there would be no discrepancy. A full PV prevents extending the LV, but it does not explain why df shows a smaller size than the already-extended LV.

The logical volume extension failed.

Why wrong: The lvextend operation clearly succeeded, often printing a confirmation with the new size and showing 500G in lvs. If the extension had failed, the LV would still be at its original size, and df would match that size exactly. The observed mismatch—500G LV but a smaller df value—is only possible if the LV was extended while the filesystem resize step was skipped.

The entry in /etc/fstab is malformed.

Why wrong: Although a malformed line in /etc/fstab is a common cause of boot-time mount failures (e.g., missing colon separators, wrong number of fields, or invalid mount options), in this scenario the entry is syntactically correct; each field is properly separated and the option list is valid. Because the syntax parses fine, the mount error must be caused by something else, such as the server being unreachable or the NFS client tools not being installed. A malformed fstab entry would show a parsing or 'wrong fs type' error at mount time, but the provided error is network-related.

The filesystem type 'nfs4' is incorrect; should be 'nfs'.

Why wrong: The filesystem type 'nfs4' is not an error; it is a valid type that explicitly designates NFSv4, the current major version, and is supported on modern Red Hat systems. In fact, /etc/fstab entries using 'nfs' are auto-negotiated and may still mount as v4, but writing 'nfs4' is perfectly acceptable and will not cause a mount failure. If the mount were to fail because of an incorrect type, the error would be 'unknown filesystem type' rather than a connectivity error, which is not the case here.

The mount point /mnt/data does not exist.

Why wrong: A nonexistent mount point would produce a distinct error: 'mount point /mnt/data does not exist' or similar, and no attempt would be made to contact the server. In this scenario, however, /mnt/data exists and is in fact a valid directory (as confirmed by an ls listing), so a missing mount point cannot be the reason for the failure. Since the mount point check passes, the problem is downstream — during the actual NFS communication or client capability setup.

The logical volume is thin provisioned and the data pool is full.

Why wrong: A thin-provisioned logical volume draws from a shared data pool: the LV can exceed the pool's actual size, but when the pool fills, all writes fail with I/O errors or 'out of space' conditions at the device mapper layer. This is not reported as a quota error, because quotas are enforced by the filesystem (XFS) based on ownership, group, or project ID, not by the underlying storage stack. The symptom would be generic ENOSPC or I/O errors, not EDQUOT.

SELinux is blocking the database writes due to a denial.

Why wrong: SELinux denials prevent access based on security contexts and are recorded in the audit log (e.g., /var/log/audit/audit.log). When SELinux blocks a write, the process receives EACCES (Permission denied), not EDQUOT ('Disk quota exceeded'). Moreover, SELinux is a mandatory access control mechanism, separate from filesystem capacity management, so it cannot produce a quota-specific error.

The filesystem has run out of inodes.

Why wrong: Running out of inodes on a filesystem means the metadata space for new files is exhausted, even if free block space remains. In this condition, attempting to create or extend a file fails with ENOSPC ('No space left on device'), not a quota exceeded error. Inode exhaustion can be diagnosed with df -i and is unrelated to project quotas, which enforce block/space limits rather than inode counts in this scenario.

mkfs.xfs /dev/sda1 && mkdir /data && echo '/dev/sda1 /data xfs defaults 0 0' >> /etc/fstab

Why wrong: This command formats /dev/sda1, but the intended device is /dev/sdb1; writing a filesystem to /dev/sda1 could destroy the operating system or an existing data partition. Even if the device were correct, the filesystem is never mounted, so /data would remain an empty directory until a reboot or a manual mount command is issued, making the fstab entry insufficient for immediate use.

mkfs.ext4 /dev/sdb1 && mkdir /data && mount /dev/sdb1 /data && echo '/dev/sdb1 /data ext4 defaults 0 0' >> /etc/fstab

Why wrong: This command uses ext4 instead of the required XFS filesystem type, so it fails the task specification even though it mounts correctly. Additionally, the fstab entry uses the defaults option, which does not enable user extended attributes; ext4 requires a separate user_xattr mount option to support user xattrs, so the resulting configuration may not meet applications that depend on extended attributes. Thus it is incorrect for this scenario.

mkswap /dev/sdb1 && mkdir /data && swapon /dev/sdb1 && echo '/dev/sdb1 /data swap defaults 0 0' >> /etc/fstab

Why wrong: This command mistakenly treats /dev/sdb1 as a swap device, but swap is not a filesystem for holding data and cannot be mounted to a /data directory. The fstab line is also invalid because a swap entry uses the swap type with a mount point of none or swap, not a directory, and swap is activated with swapon, not mount. Therefore this option is fundamentally wrong.

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

Why wrong: Running mkfs.xfs /dev/sdb without -f will not overwrite anything; XFS detects the existing partition table and aborts with an error. Even if you added -f, it would obliterate the partition table and place the XFS superblock at the beginning of the raw disk, leaving no partition entry — a non-standard configuration that many systems won't recognize as a usable storage device. The correct procedure is to create a partition first.

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

Why wrong: This LVM approach is technically executable but completely unnecessary and fails the stated requirement: you would not create a filesystem on the whole disk, but rather on a logical volume carved from a volume group, adding PV/VG/LV layers of indirection. The question asks for a single filesystem on /dev/sdb, and the expected solution uses a standard partition, not LVM. In the exam scenario, LVM is not configured, and the logical volume device (/dev/vg0/lv0) is not a directly usable partition entry on the disk.

Save and exit the crontab file first, then edit it again to add the line '30 2 * * * /path/to/script'.

Why wrong: Saving and exiting before adding the entry means the crontab editor writes the unmodified cron table back, leaving the existing jobs (or nothing) exactly as they were. The new line '30 2 * * * /path/to/script' was never inserted, so the save cannot include it; a subsequent 'crontab -e' session is a separate operation, but starting it does not retroactively apply the earlier save. The correct action is to add the line within the same editing session, because the editor will only write what is present when you save. This option also creates a pointless two-step process where the first save contributes nothing.

Exit the crontab editor immediately, then edit the file again with 'crontab -e' and add the line '30 2 * * * /path/to/script'.

Why wrong: Exiting the crontab editor immediately, with no changes made, simply closes the editor and the crontab is unchanged; no job is scheduled. After that, opening 'crontab -e' a second time and adding the line would work, but the first exit was unnecessary and did not help create the job. The correct sequence is to remain in the initial editing session, insert the cron line, and then exit with a save — an early exit cannot be combined with later edits because each session starts from the currently stored crontab. This option mistakes the app-level edit operation for a shell command sequence, when in fact the line must exist in the buffer before save.

df: Create a filesystem

Why wrong: df (disk free) reports the amount of used and available space on mounted filesystems, reading from the kernel's statfs interface, as in 'df -h'. It does not create or format anything; filesystem creation is performed by mkfs and physical partitioning is done by fdisk or parted. Interpreting df as a filesystem-creation tool confuses a read-only monitoring utility with a destructive setup tool.

lvcreate: Display disk usage

Why wrong: lvcreate does not display disk usage; it is an LVM command that creates a new logical volume from a volume group, using syntax such as 'lvcreate -L 10G -n data vg01'. Disk usage reporting is the job of df (for filesystem-level usage) or du (for directory-level usage), which query the kernel's mounted-filesystem statistics. Choosing lvcreate for this function conflates a storage-provisioning action with a reporting activity.

fdisk /dev/sdb1

Why wrong: fdisk /dev/sdb1 is incorrect because fdisk is a disk-partitioning utility that manipulates partition tables (MBR or GPT) on a whole disk device such as /dev/sdb. Running it against the partition node /dev/sdb1 would not create an ext4 filesystem; instead, it would treat the partition itself as a disk to be repartitioned, potentially destroying existing data or the partition table itself. fdisk has no functionality for writing filesystem metadata like the ext4 superblock.

parted /dev/sdb1

Why wrong: parted /dev/sdb1 is incorrect because parted is an interactive partition editor used to create, resize, and delete partitions on a disk. Although it can tag a partition with a filesystem type string for informational purposes, it does not actually write the ext4 structures (superblock, inode table, block groups) onto the partition. Invoking parted on /dev/sdb1 would open the partition for partition-table operations, which is meaningless and could corrupt the partition's contents, but it cannot initialize a new filesystem.

tune2fs /dev/sdb1

Why wrong: tune2fs /dev/sdb1 is incorrect because tune2fs is a tool for adjusting tunable parameters on an existing ext2/ext3/ext4 filesystem, such as reserved block percentage, check intervals, or volume labels. If /dev/sdb1 is raw and has no filesystem, tune2fs will fail immediately because it cannot read a valid superblock. It is not a creation utility and would never be used as the first step to set up a filesystem.

fsck /dev/sdb1

Why wrong: fsck /dev/sdb1 is incorrect because fsck (filesystem check) is designed to validate and repair the consistency of an existing filesystem, not to create one. On a raw /dev/sdb1 that has never been formatted, fsck will report that the superblock is invalid and abort without writing anything. It is a maintenance tool, so running it before mkfs.ext4 would be pointless and could yield misleading error messages.

lvextend -L +10G /dev/vg_data/lv_data; mount /dev/vg_data/lv_data; resize2fs /dev/vg_data/lv_data

Why wrong: The lvextend command grows the logical volume's block device, but the filesystem still needs resize2fs to use the extra space. Running mount on the logical volume is redundant if the filesystem is already mounted; if it is unmounted, resize2fs can still be run directly on the block device. Attempting to mount an already-mounted LV can produce a 'device is busy' error or shift the active mount, so the mount step should be omitted.

lvextend -L +10G /dev/vg_data/lv_data; mkfs.ext4 /dev/vg_data/lv_data

Why wrong: Running mkfs.ext4 on the logical volume will recreate an empty ext4 filesystem, erasing all existing data, metadata, directories, and file contents stored in the LV. The lvextend only changes the block device size; it does not reformat the filesystem. After extending, the correct step is resize2fs to grow the existing filesystem while preserving data, not replace it with a new filesystem.

lvresize -L +10G /dev/vg_data/lv_data; fsck /dev/vg_data/lv_data

Why wrong: lvresize -L +10G achieves the same size increase as lvextend, but fsck is the filesystem integrity checker and does not change the filesystem size. After growing the LV, you must run resize2fs to expand the ext filesystem into the newly added space. Furthermore, running fsck on an active or mounted filesystem is unsafe and may cause corruption, so this pair does not complete the extension requirement.

vgextend vg_data /dev/sdd1; lvextend -L +10G /dev/vg_data/lv_data; resize2fs /dev/vg_data/lv_data

Why wrong: vgextend vg_data /dev/sdd1 would add /dev/sdd1 as a new physical volume to the volume group, but this is only necessary when vg_data lacks sufficient free extents. The question states the LV is already in an existing volume group with enough free space, so vgextend is an unnecessary and potentially harmful extra step (the device may not be a dedicated PV). The required actions are simply lvextend to allocate more extents from the existing VG free pool and then resize2fs to grow the filesystem.

Shrink the filesystem on 'lv_archive' to free space, then use vgsplit to move the space to 'lv_share'.

Why wrong: Shrinking the filesystem with resize2fs only releases space inside lv_archive; it does not return extents to the volume group, because those blocks are still part of the logical volume. The vgsplit command moves entire physical volumes (PVs) to a new or different volume group, not free space from an LV, so it cannot relocate the now-unused filesystem space to lv_share. Even if you then reduced lv_archive, vgsplit still would not allocate that free space to another LV in the same VG.

Use lvreduce directly on 'lv_archive' without changing the filesystem, then lvextend on 'lv_share'.

Why wrong: Running lvreduce directly on lv_archive without first shrinking its filesystem with resize2fs truncates the logical volume while the filesystem metadata still points to blocks beyond the new size, causing severe data corruption or an unmountable filesystem. The subsequent lvextend on lv_share would allocate the freed extents, but the source LV is already damaged and may be unrecoverable. There is no mechanism to 'catch' the filesystem data in the leftover extents; the filesystem must be resized before the device.

Use lvresize to reduce 'lv_archive' and extend 'lv_share' in one command.

Why wrong: The lvresize command can resize a single logical volume in either direction with -L, but it has no ability to transfer or move extents between two unrelated logical volumes within the same volume group. To give space from lv_archive to lv_share, you must first reduce lv_archive (after shrinking its filesystem) to return extents to the VG, then separately extend lv_share. A single lvresize invocation cannot atomically shrink one LV and grow another, and attempting to specify both targets would be syntactically invalid.

Add a new physical volume to the volume group instead.

Why wrong: Adding a new physical volume and extending lv_share with pvcreate/vgextend/lvextend increases the volume group's total capacity, but it does not reduce or reuse any space currently consumed by lv_archive. The task explicitly asks to use existing space from lv_archive, so this approach would also require an additional physical disk (or a partition) and leaves lv_archive at its original size, failing to satisfy the reallocation requirement. It also involves creating a new PV, which is not the intent when free space already exists within the VG.

mount -a

Why wrong: mount -a attempts to mount every filesystem listed in /etc/fstab. If the fstab entry for /dev/sdb1 contains an incorrect or missing UUID, mount will fail with a device-not-found error, and the command itself will not tell you the correct value; it only consumes what is already in the file. In a boot-failure scenario the administrator must first query the device with blkid, then correct fstab before mount -a can succeed.

xfs_info /dev/sdb1

Why wrong: xfs_info /dev/sdb1 is a diagnostic tool intended solely for XFS filesystems; it reports geometry, block size, and other XFS-specific allocation data, not the filesystem UUID. If /dev/sdb1 holds a non-XFS filesystem (or is not mounted), xfs_info exits with an error, so it cannot serve as a general-purpose UUID query on this device.

fdisk -l /dev/sdb1

Why wrong: fdisk -l /dev/sdb1 shows the partition table layout: start/end sectors, size, and partition type ID (such as 83 for Linux) are displayed, but filesystem UUIDs are not part of fdisk's output. fdisk operates on the partition table itself, not the filesystem's superblock, so no UUID of an ext4 or XFS filesystem is revealed. To report the UUID you must use a tool that reads the filesystem metadata, like blkid.

lsblk -f /dev/sdb1

Why wrong: lsblk -f /dev/sdb1 does display the filesystem type and UUID in a tree-like format, so it is not useless, but it is an interactive-oriented listing tool rather than the primary command for a single device's raw attributes. Its output is padded and formatted for human readability, whereas blkid emits parsable key=value pairs directly from the device; in an exam or a boot-recovery script, blkid is the standard and more direct way to obtain a UUID.