There are four entries in /dev/disk which I am interested in.
by-id
by-label
by-path
by-uuid
Which of the entries contain immutable names for physical drives? By immutable, I mean that the name shouldn't change if I
change the usb/pci port used to connect to the drive.
destroy and create partitions (GPT).
move from one computer to another (external hard-drive).
For example, /dev/sda can change to /dev/sdb if a different flash drive is connected. But the UUID stays the same. I don't mind if a partition's path changes (I think the UUID changes if you destroy and then recreate a partition), but the complete physical drive must stay at the same location (/dev/sdX may change, but the UUID doesn't when the usb port is changed).
Please suggest relevant tags.
Edit -
Can you say the same for partlabel and partuuid?
In short: you can use by-label or by-uuid to keep names immutable.
In detail:
Disk names (/dev/sdX) are given by kernel based on controller priority (master/slave) disk attached to. If you are moving disk from one USB port to another, for kernel it is like switching a controller. This is why names are changed from /dev/sda to /dev/sdb.
The directory /dev/disk is related to filesystem located on the disk. Label and uuid are filesystem attributes which are given on filesystem creation and can be changed after.
They are immutable and can survive:
disk migration from one computer to another.
disk migration from one controller to another on same computer.
However by-label and by-uuid will not survive if you destroy the partition, but the same label, uuid names can be given upon filesystem creation. So newly created filesystem will be mounted at same mount point.
I personally prefer to use by-label as it supported by many filesystems, short and descriptive.
More information about persistent block device naming.
Related
I came across uuidgen from watching a video to study for the redhat 8 exam but I had a question about it's usefulness and did not find any other thread nor did the manpage mention it. So I understand that each device has an UUID and the UUID can be used for multiple purposes - the purpose in the video was creating new mountpoints and the UUID was used to associate a new partition (/dev/sdb3) with a new mountpoint. Here they pointed out that you can generate a new UUID for that device using uuidgen.
My question is why/when would you use uuidgen in a production environment with live servers to relabel a partition? What would be the point of relableing the UUID for a currently existing mountpoint? Is there a sort of attack that target UUID of a system? Or is the sole purpose for uuidgen just used to create random UUIDs for others things like web links?
Thanks
Say you have a system with several disks, one partition each, and you need to play "Musical Data" with some of them.
If you start by copying, at block level via e.g. dd, the entire GPT-partitioned disk, then you will have, as a result, a duplicate UUID. This is fine if one of the duplicates is going to be blown away before the next time the OS needs to mount one of them. If, for whatever reason, this can not be ensured, then whichever copy you don't want the OS to pick up anymore, needs a new UUID. Enter uuidgen.
I'm assuming you're talking about GPT partition UUIDs, which are stored all together in each GPT that contains the identified partitions; if, instead, you're talking about filesystem UUIDs, which are stored inside the metadata for that filesystem and thus are copied whenever dd'ing that filesystem, then the above scenario still holds and more scenarios become plausible.
I'm reading Operating System Concepts by Avi Silberschatz(9thE), in section 11.4 File-System Mounting, the author explains the steps of filesystem mounting as follows:
The operating system is given the
name of the device and the mount point—the location within the file structure
where the file system is to be attached.
Next, the operating system verifies that the device contains a valid file
system.
Finally, the operating
system notes in its directory structure that a file system is mounted at the
specified mount point.
I'm confused with the final step, since to the best of my knowledge, the directory structure is stored somewhere on the disk, which records the files' information -- such as name, location, size, and type. Then what does the author mean by directory structure in operating system? Is it the same directory on disk?
Additionally, which part finishes the conversion from file name to physical address on disk? Is it the disk driver or the disk controller or done by processor with memory?
What you are reading is largely nonsense. To begin with, it is eunuchs specific. Eunuchs variants tend to have a single directory structure containing all disks and even things that are not really files.
Let us assume that you are on Windoze. If you mount a disk the drive gets a name, typically a single letter but larger names are possible in some cases. Let's say you mount a disk drive, and the system assigns it to "Q:".
So now Q: is available and you can access files, by specifying something like
"Q:\dir1\dir2\file.type"
You are just accessing the directory structure that exists on Q:.
Each drive has a separate, independent directory structure.
Many operating system operate this way and your sequence above is irrelevant to them.
Eunchs variants do not work this way. The system maintains a single directory starting at "/" which is the root directory for the system. This is a directory maintained by the operating system and does not exist at all on a disk drive.
On a Mac, for instance, there is a "/Volumes" directory that contains all the drives mounted. These too are directories maintained by the operating system and do not exist at all on a disk drive.
"/Volumes/Macintosh HD"
"/Volumes/Backup Drive"
These system directories then link to the directories that are stored on those disks. Thus, in Eunuchs, there are directories maintained by the operating system and directories maintained on the disk that are merged together.
So if you want to find "/Volumes/Backup Drive/dir/something.txt" the system goes to the root "/" finds "Volumes" and determines this is a system directory. Finds "Backup Drives" and determines this is a disk drive that has been mounted. Goes to the root directory of the drive and find that "dir" is a directory on the drive, and finds the file something.txt.
To add to the confusion, there are disk formats that have no directory structure at all. But this illustrates that your book is taking you on a confusing path.
Each disk drive has a format of some kind. E.g., NTFS, ODS-11, FAT, ....
What I am telling you from here on is generalization of what typically happens but there are large variations in how it works among systems.
Typically, each drive will have a header that includes a description of block clusters in use (often a bitmaps) and files on the disk. The file description will usually have a file name, date created, owner, etc. The file description will also have information about where the data is stored on the disk.
The drive often will have a directory structure in which there is some file it defines as the root directory. The directory structure exists by creating directory files within other directory files. A directory is normally just a file that has a list of file names and the address of their description in the the disk header. Other file attributes, such as the file size and date of creation, are not stored in the directory.You get that from the file description in the disk header.
The file structure in the disk header is separate from the directory structure. In fact, it is often possible to create a file that is not even in a directory at all. Or you can put a single file in multiple directories.
If your disk gets trashed and has to be recovered, this is usually done by looking at the disk header. You get back your files but lose your directory structure.
Additionally, which part finishes the conversion from file name to physical address on disk? Is it the disk driver or the disk controller or done by processor with memory?
The logical location on the disk is specified in the file description in the disk header. The format of that information is specific to the underlying disk format. Generally you have two paths to reach the file description:
You can go through the list of file headers maintained by the disk; or
You can navigate a directory structure until you find the file name you want with a link to the file description.
I was under the impression that a block device is listed under /dev, so for example /dev/xvdf and that file systems live on a partition which is listed with a number behind the block device the partition is on, like /dev/xvdf1 and that all file systems must live on a partition.
I am running CentOS and as part of a course I have to create file systems, partitions and mount file systems. For this course, I have created a file system on device file /dev/xvdf and I have mounted this file system. In addition to that, I have created a partition on /dev/xvdf with the file name of /dev/xvdf1 and created a file system on this partition as well and mounted this file system. This confuses me and I have some questions:
Am I correct that you do not have to create a partition on a block device, but that you can create a file system on a block device directly without a partition?
If so, why would anyone want to do this?
After creating the file system on /dev/xvdf, I created the /dev/xvdf1 partition using fdisk and I allocated the max blocks to this new partition. However, the file system on /dev/xvdf was not removed and still had a file on it. How is this possible if all the blocks on /dev/xvdf have been allocated to the /dev/xvdf1 partition?
Question #1: you are correct. A file system needs only a contiguous space somewhere. You can also create file system in memory (virtual disk).
Question #2: the possibility of having a partition table is a good thing; but why use it if you don't need to break a disk (or other block device) in several pieces?
About question #3, I think you overlooked something - probably an error raised somewhere and you didn't notice, or some error will raise in future. Even if you have the impression, it can not work; the mounted filesystem thinks to own all the space reserved to it, and similarly fdisk thinks that the blocks it is using "can be used". BTW, what is that "/dev/xvdf"? Is it a real device or whatever?
I did some web searches for this, but could only find results about getting the kernel module associated with a device node. Is there anyway I can get the major and minor numbers of the current system's root device and, if applicable, the root device's parent device (e.g., /dev/sda is the "parent" of /dev/sda2)? Does the kernel export some functions for getting this or would I need to get it indirectly?
There is no module associated with a device node. Possibly you know that the root directory is something local to a process (the process structure stores the inode reference for the root directory --- and this can be changed with the privileged chroot(2) system call) and the current working directory (to solve for paths not beginning with /)
If you want to know the device responsible of the root directory you have two options:
Your process has not been made a chroot(2) syscall, so you opendir("/") and then do a fstat(2) on it (or you can do a stat(2) syscall on the "/" directory). This will give the device in which the root directory resides as the st_dev field of the struct stat returns. It is formatted as a dev_t number, in which some of the bits represent the major number and some the minor number. You can use the MKDEV(ma,mi) and MAJOR(dev) and MINOR(dev) macros defined in <linux/kdev_t.h> to access the major and minor numbers. To get the physical disk, just mask the minor number with 0xf0 and you will get the minor number of the whole disk.
your process has made a chroot(2) syscall, so you are not allowed to access the real root directory in the system. If you have access to the /proc filesystem, then probably you can call mount(1) command to get the mount table. you can search that table for the / entry, and then get the /dev/sd<disk> entry. Once you got the device, getting the parent device is easy. You can mask the number as you did in the last point to get the minor number of the physical disk.
You can also get to the /proc/diskstats file, that shows you the statistics of each block device. You'll get the major, minor and device name in the first three fields of each line.
NOTE
There are some disk arrangementes that dont't allow partitioning, as RAID devices or volume manager disks. In those cases, getting to the physical disk (or disks, as there can be more than one) is more difficult.
If I have a device mounted in RHEL, how do I add another device to it and make it a raid0 config?
I know how to mount two new devices in a raid0 config, but how do I do it with one device that is already in use and has data on it?
Depends on the details; is it an lvm volume? Then add the new device to the volume group and extend the logical volume. Is it a file system like ZFS? Then add the device to the pool. Otherwise, you need to backup the mounted drive, unmount and create a raid0 volume.
Save you some headaches and clone the drive with a disk imaging software like Clonezilla (http://clonezilla.org/).
Once you have your drived cloned as a disk image, set up RAID0 and recover your clone to the newly created RAID, telling Clonezilla to expand to the total size of the disk.
This way, even if something goes wrong, you can always undo the whole process and just recover your clone into the original single disk as if nothing happened.
Hope it helps,
Regards
I don't think it's possible. You can't have a mounted drive and convert it into a RAID array along with another drive. You will surely have to unmount it first. More realistically, you'll probably have to reformat the drive before adding it to a RAID array. Understand that the RAID is being managed at a lower level than the OS. The OS sees the RAID array as one partition. The OS has no ability to manage or add drives to an existing RAID array.