- Home
- Server Administration
- LPIC-1 Linux Administrator 101
56.
What is an advantage of a journaling filesystem over a conventional (non-journaling)
filesystem?
- A.Journaling filesystems are older and better tested than non-journaling filesystems.
- B.Journaling filesystems never need to have their filesystems checked with fsck
- C.Journaling filesystems support Linux ownership and permissions; non-journaling filesystems don’t.
- D.Journaling filesystems require shorter disk checks after a power failure or system crash.
- E.Journaling filesystems record all transactions, enabling them to be undone.
- Answer & Explanation
- Report
Answer : [D]
Explanation :
Explanation :
| The journal of a journaling filesystem records pending operations, resulting in quicker disk checks after an uncontrolled shutdown, so option D is correct. Contrary to option A, journaling filesystems are, as a class, newer than non-journaling filesystems; in fact, the journaling ext3fs is built upon the non-journaling ext2fs. Although disk checks are quicker with journaling filesystems than with non-journaling filesystems, journaling filesystems do have fsck utilities, and these may still need to be run from time to time, so option B is incorrect. All Linux-native filesystems support Linux ownership and permissions; this isn’t an advantage of journaling filesystems, contrary to option C. The journal of a journaling filesystem doesn’t provide an unlimited “undo” feature, so option E is incorrect. |
57.
To access files on a USB flash drive, you type mount /dev/sdc1 /media/flash as root.
Which types of filesystems will this command mount?
- A.Ext2fs
- B.FAT
- C.HFS
- D.ReiserFS
- E.All of the above
- Answer & Explanation
- Report
Answer : [E]
Explanation :
Explanation :
| When typed without a filesystem type specification, mount attempts to auto-detect the filesystem type. If the media contains any of the specified filesystems, it should be detected and the disk mounted, so option E is correct. |
58.
Which of the following /etc/fstab entries will mount /dev/sdb2 as the /home directory
at boot time?
- A./dev/sdb2 reiserfs /home defaults 0 0
- B./dev/sdb2 /home reiserfs defaults 0 0
- C./home reiserfs /dev/sdb2 noauto 0 0
- D./home /dev/sdb2 reiserfs noauto 0 0
- E.reiserfs /dev/sdb2 /home noauto 0 0
- Answer & Explanation
- Report
Answer : [B]
Explanation :
Explanation :
| The /etc/fstab file consists of lines that contain the device identifier, the mount point, the filesystem type code, filesystem mount options, the dump flag, and the filesystem check frequency, in that order. Option B provides this information in the correct order and so will work. Option A reverses the second and third fields but is otherwise correct. Options C, D, and E all scramble the order of the first three fields and also specify the noauto mount option, which causes the filesystem to not mount automatically at boot time. |
59.
What filesystem options might you specify in /etc/fstab to make a removable disk
(USB flash drive, Zip disk, floppy disk, and so on) mountable by an ordinary user with a
UID of 1000? (Select three.)
- A.user
- B.users
- C.owner
- D.owners
- E.uid=1000
- Answer & Explanation
- Report
Answer : [A, B, C]
Explanation :
Explanation :
| The user, users, and owner options in /etc/fstab all enable ordinary users to mount a filesystem, but with slightly different implications: user enables anybody to mount a filesystem, and only that user may unmount it; users enables anybody to mount a filesystem, and anybody may unmount it; and owner enables only the owner of the mount point to mount or unmount a filesystem. Thus, options A, B, and C are all correct. The owners parameter of option D doesn’t exist. The uid=1000 parameter of option E tells Linux to set the ownership of files to UID 1000 on filesystems that lack Linux permissions features. Although this might be desirable for some disks, it doesn’t enable the user with UID 1000 to mount the disk, so option E is incorrect. |
60.
What is the minimum safe procedure for removing a USB flash drive, mounted from /dev/
sdb1 at /media/usb, from a Linux computer?
- A.Type umount /media/usb, wait for the command to return and disk-activity lights to stop, and then unplug the drive.
- B.Unplug the drive, and then type umount /media/usb to ensure that Linux registers the drive’s removal from the system.
- C.Unplug the drive, and then type sync /dev/sdb1 to flush the caches to ensure problems don’t develop.
- D.Type usbdrive-remove, and then quickly remove the disk before its activity light stops blinking.
- E.Type fsck /dev/sdb1, wait for the command to return and disk-activity lights to stop, and then unplug the drive.
- Answer & Explanation
- Report
Answer : [A]
Explanation :
Explanation :
| Option A correctly describes the safe procedure for removing a removable medium that lacks a locking mechanism from a Linux computer. (Instead of typing umount /media/ usb, you could type umount /dev/sdb1; in this context, the two commands are equivalent.) Option B reverses the order of operations; the umount command must be typed before you physically remove the flash drive. Option C also has it backward; the sync command would need to be issued before removing the drive. (The sync command can prevent damage when removing disks, but it isn’t a complete substitute for umount.) There is no standard usbdrive-remove command in Linux, and if you were to write a script that calls umount and call it usbdrive-remove, pulling the flash drive quickly, as option D describes, would be exactly the wrong thing to do. The fsck command of option E checks a filesystem for errors. It’s not necessary to do this before removing a disk, and it won’t unmount the disk, so option E is incorrect. |
|
|
||||||||||||||||||||||||||||
