Why doesn't Linux have a C drive? Does it have any benefits?
Because it is a very old and silly way to access disks and filesystems.
Starting with Unix v1, it was realized that the only reason a reference to a physical device exists is to be able to do things with it. Thus some way for the computer to access the driver for the device is needed. Since there are multiple devices attached a generic way got used.
The older history, this was done by using a letter or combination of letters - where the combination provided the class of device: thus CON (console) TTY0,TTY1,TTY2… *(terminals), and for disks: DSKA, DSKB,DSKC….
Thus CON would look in a table for console devices (which might be redirected to a terminal), and TTY was the table for terminals, DSK was the table for disk drives.
Starting with Unix v1, it was realized that the only reason a reference to a physical device exists is to be able to do things with it. Thus some way for the computer to access the driver for the device is needed. Since there are multiple devices attached a generic way got used. Since the people writing the file system were also the ones writing the device drivers, they realized that there was no need to have two parsing operations - one for disk files, and one for device names. So instead they created "device files", something the filesystem could handle during lookup, but instead of passing the result to start reading data… it instead recognized that these were special, and thus passed them to the single table containing devices.
Now that table contained multiple entries - one for each different type of device (terminals, disks, and other things), the file metadata (specifically the bits used for file size) got broken up into two fields, one for the type of device (the major number), and one for the specific attached device (the minor number).
So instead of using the simplified "A", "B", "C" names from the 60s, Unix used a file name. And that allowed the devices to be identified in any way the administrator would want. Hence Linux, which inherited this, and has things like /dev (the collection of device names), and /dev/sda0.
Now it CAN be named anything as the name is just a convention to identify the device. In general "sd" is short for "scsi disk", and the "a" follows the older lettering style for device units, and the number following is generally used to identify the partition.
Not all devices follow that though - there are occasions when you see /dev/cdrom, or /dev/dvd0, /dev/dvd1… These are still disks - and frequently can be found with names like /dev/sr0… these are also scsi disks (simply because the conventional starting letter is "s"), but the "r" letter indicates "raw device" (which is also a convention). It is the indexing values attached to the name that are important. When the name happens to be a symbolic link, the link is followed by the file system to get to the targeted name - and THEN the special characteristics are recognized.
One of the special characteristics is that a device can generally only be used by one process at a time. So when the device is open, it is marked "busy" (or "in use"). This contributes to the ability for a filesystem to be mounted from a device.
When this is done, the mount command will examine the header of the disk, identify the filesystem to be used (looked up in another table), and the mount point (a directory), has its in-memory representation modified so that the directory gets connected to the root directory of the filesystem on the targeted device. The device is marked busy because now the file system code takes over the use of the device.
Now names of files can go through the mountpoint (the directory used when the file system is mounted), and continue processing files normally - and handing off the processing to whatever filesystem was designated for the partition.
All transparent to the user, and just making it look like the system has a REALLY big storage capacity for files.
All of this was figured out and implemented from the early 1970s.
Microsoft developers just never picked up the better organization, and remained with the methods used in the early 1960s. Then claimed "backward compatibility" just because they didn't want to do anything about the outdated use, and continues doing it to this day.
Because it is a very old and silly way to access disks and filesystems.
Starting with Unix v1, it was realized that the only reason a reference to a physical device exists is to be able to do things with it. Thus some way for the computer to access the driver for the device is needed. Since there are multiple devices attached a generic way got used.
The older history, this was done by using a letter or combination of letters - where the combination provided the class of device: thus CON (console) TTY0,TTY1,TTY2… *(terminals), and for disks: DSKA, DSKB,DSKC….
Thus CON would look in a table for console devices (which might be redirected to a terminal), and TTY was the table for terminals, DSK was the table for disk drives.
Starting with Unix v1, it was realized that the only reason a reference to a physical device exists is to be able to do things with it. Thus some way for the computer to access the driver for the device is needed. Since there are multiple devices attached a generic way got used. Since the people writing the file system were also the ones writing the device drivers, they realized that there was no need to have two parsing operations - one for disk files, and one for device names. So instead they created "device files", something the filesystem could handle during lookup, but instead of passing the result to start reading data… it instead recognized that these were special, and thus passed them to the single table containing devices.
Now that table contained multiple entries - one for each different type of device (terminals, disks, and other things), the file metadata (specifically the bits used for file size) got broken up into two fields, one for the type of device (the major number), and one for the specific attached device (the minor number).
So instead of using the simplified "A", "B", "C" names from the 60s, Unix used a file name. And that allowed the devices to be identified in any way the administrator would want. Hence Linux, which inherited this, and has things like /dev (the collection of device names), and /dev/sda0.
Now it CAN be named anything as the name is just a convention to identify the device. In general "sd" is short for "scsi disk", and the "a" follows the older lettering style for device units, and the number following is generally used to identify the partition.
Not all devices follow that though - there are occasions when you see /dev/cdrom, or /dev/dvd0, /dev/dvd1… These are still disks - and frequently can be found with names like /dev/sr0… these are also scsi disks (simply because the conventional starting letter is "s"), but the "r" letter indicates "raw device" (which is also a convention). It is the indexing values attached to the name that are important. When the name happens to be a symbolic link, the link is followed by the file system to get to the targeted name - and THEN the special characteristics are recognized.
One of the special characteristics is that a device can generally only be used by one process at a time. So when the device is open, it is marked "busy" (or "in use"). This contributes to the ability for a filesystem to be mounted from a device.
When this is done, the mount command will examine the header of the disk, identify the filesystem to be used (looked up in another table), and the mount point (a directory), has its in-memory representation modified so that the directory gets connected to the root directory of the filesystem on the targeted device. The device is marked busy because now the file system code takes over the use of the device.
Now names of files can go through the mountpoint (the directory used when the file system is mounted), and continue processing files normally - and handing off the processing to whatever filesystem was designated for the partition.
All transparent to the user, and just making it look like the system has a REALLY big storage capacity for files.
All of this was figured out and implemented from the early 1970s.
Microsoft developers just never picked up the better organization, and remained with the methods used in the early 1960s. Then claimed "backward compatibility" just because they didn't want to do anything about the outdated use, and continues doing it to this day.
No comments:
Post a Comment