| The FileMe page,
the one about the
filesystem tree |
| Paragraphs
in
this
page
are:
Tree File Types The Tree Logic Common Filesystem Types Reporting - Mounting - Unmounting Filesystems a) Tree This page goes to the 2nd level, assuming that in the first level, the user would be limited to his/her ~home. But now, since pages about configuration files etc. are the case of study, it is most useful to have a look at the linux filesystem tree:
There are strong similarities in this tree in every *nix.
Q: What's the /usr purpose since there are /bin /lib /etc /var etc.? A: In general, /usr is for program installation. In reality, /usr holds all the rest that is not needed to bring the system up. Directories can be real filesystems. How would a *nix use a different patrition before having the ability to mount it? So, the basic structure , as well as basic administrative tools, have to be initially located in the filesystem that boots. If foo was a user, then /home/foo would be his/her home. It is a good strategy to mount all the filesystems that are not part of our system, (but just for external reference, or archiving) in /mnt for better structure. In Suse distros, the directory /media replaces /mnt but has the same role. If you have plenty of free space, it is a good advice to have: /home , /usr , /var in separate partitions or physical disks. /usr because it is really big. /home for not losing the user directories in case of a new OS install. /var for not losing your http/database server data, if you create ones. But you can re-arrange ftp and http roots inside /home, for example: /home/ftp some distros do it by themselves. /home/http or /home/webroot or whatever you want. I have also created directories accessible from all users: /home/shared/documents /home/shared/documents/help /home/shared/documents/webroot /home/shared/documents/wallpaper /home/shared/documents/stereograms etc. but not as root, so that when I change them or their contents, I can do so as a regular user. Keep in mind to that no matter how many users are served by your linux box, one of them (you) might do things that other users wouldn't, like the additional directories added above. Be root only when needed, i.e. to create or modify the ftp account etc. |
|||||||||||||||||||||||||||||||||||||||||||||||
b) File Types As you have seen in the other pages (specially in the TipMe Page) the filesystem tree is mostly unified. This means for example that you can interact with the devices that are part of your system. Here is an example from the AmazeMe page: cat /etc/inittab > /dev/dsp you will hear noise. or another one, not very userul in first sight, but who knows? assuming that /dev/modem is well configured and it is not used by an application and you have permissions: cat /etc/passwd > /dev/modem you will see the modem leds work! cat /dev/mouse > /dev/modem move your mouse and see! cat /dev/mouse > /dev/dsp move your mouse and hear! But mouse has to be unused or else the device will be blocked! The interaction with the devices is very open and able to usable in scripts. Q: So what file types do I have? A: A few that you will recognize instantly and many that are new:
Soft (or symbolic) and Hard Links: Soft links are files that point to other files in such a way that every operation we do on them is like operating the original file. So, operating /dev/mouse and /dev/psaux is the same provided that: /dev/mouse points correctly to /dev/psaux path and: your mouse Is a PS/2 one! A soft link is more than a shortcut like the ones the average user is familiar with. In reality, a Soft Link points to the original file's path. The soft link inherits the original file's role and permissions. Soft Links can point to Directories, too. Hard Links are files that instead of pointing to a files path, they point to the inode (position INSIDE the filesystem), thus being an exact copy without replication! Using Hard Links, a file can have more than one name!
Special Files a) Device files Device files are grouped in two types: Character Device Files and Block Device Files Character devices work with small streams of data, possibly need a more frequent attention from the kernel and this data (bytes or bits) is not cached in the memory. Block devices work with blocks of data (mainly bytes) which needs to be cached in memory buffers, and do not need attention from the kernel as frequent as character devices do. Some character device files in Linux: /dev/psaux for the PS/2 port /dev/ttyS0 for the Serial (Com) Port 1 /dev/lp0 for the Parallel Port 1 (if only, in most home computers) Also Ethernet cards etc. Some block device files: /dev/fd0 for the first floppy drive /dev/hda for the primary master ide/atapi [hard or compact] disk /dev/sda for the first scsi [hard or compact] disk /dev/sr0 for the first emulated scsi device: hard/compact disk, flash memory etc. In FreeBSD (and possibly in the others, too), storage hardware is presented by the kernel as character device files. b) Fifo Files Fifo files are named pipes in the filesystem. They are files that act as data channels between programs. For example: If program1 points its output to a fifo file and program2 reads its input from the fifo file it would be as: program1 | program2 Nothing is actually written to the filesystem.
Note: The Device Files are NOT drivers. Drivers are either loadable kernel modules or internal kernel code. Device Files are files for interaction with the kernel. |
|||||||||||||||||||||||||||||||||||||||||||||||
c) The Tree Logic As you can see from the first two paragraphs, everything is visible in *nix systems: filesystems, device files, hardware, kernel environment etc. may "overdose" a new user browsing the "inside" of their Linux Box. Files in *nix are generally organized by "type", and not "thematically". This means that: All the executables are located in "bin" directories. All the libraries " " " "lib" directories etc....etc....
Configuration files exist in user home directories also. Linux Kernel modules are located in /lib/modules FreeBSD Kernel mocules are located in /modules The Kde dirs may vary among Distros: /usr/kde /usr/kde3 or merged entirely in /usr. All the binary dirs are in the PATH variable. In some Distros, only root has /sbin or /usr/sbin in the path. Include files are, simply put, headers that tell to new installations (mainly source) how to use the existing libraries. There are more locations than the ones mentioned in the above table. Q: I "think" I've understood the logic. But why does /usr/local exist with all the subdirs (bin lib etc include) in it? /usr is not enough? A: /usr/local is used to distinguish between the installed system and "new" program, library etc. additions, that generally are compiled from source. In FreeBSD, /usr/local contains everything that is not "base" system. As you see, somehow different file organization exists between Linux Distros as well as *nix systems in general. But the structure is generally the same. In the a) paragraph, I mentioned that /home , /usr , /var can be located in separate partitions or physical disks. /usr/local or /opt can also apply to this logic.
d) Common Filesystem Types 1) Local (inside the local computer)
2) Remote (accessible as a network resource)
e) Reporting - Mounting - Unmounting Filesystems To report all mounted filesystems, issue as root or simple user: mount To report all network filesystems, issue as root or simple user: mount -t nfs For reporting the Fat32 mounted filesystems, here is a command : mount -t vfat To report all mounted filesystems along with space usage info: df -h The next logical step would be to fully study the two commands : man mount ; man df When trying to mount a filesystem that is not in /etc/fstab remember that: 1) Only root can do that 2) The mount point must exist 3) Device file & mount point must be mentioned, while type and options may be omitted. In the contrary, if a filesystem is mentioned in /etc/fstab and not mounted, then: 1) Any user can do the mount if the option user is mentioned 2) The mount point most probably exists 3) Only the mount point has to be mentioned. fstab will be consulted for all other info. *) But for manual mount of a mentioned (in fstab) filesystem, options must include noauto. To unmount a non busy filesystem remember these small tips: 1) The regular user that mounted it can unmount it (user in fstab options) 2) A different regular user can do the unmount if the option users is mentioned. 3) root can always do the unmount 4) the command umount can accept multiple entries: umount /mnt/c /mnt/d /mnt/nfs/filer If the filesystem to be unmounted is busy, that means that a process (e.g. shell) is currently accessing it. To know about all processes that use e.g. the /mnt/c mount, just use the list open files utility: lsof /mnt/c Then act accordingly. It would be wrong to kill a copy in progress of course. Unmounting a filesystem and remounting it with different options can be issued in a single step. If /home is in reality another filesystem e.g. /dev/hda5, only root is logged in and a filesystem check is to be done, then issuing as root: mount /dev/hda5 /home -o remount,ro would do the trick. The filesystem type can be omitted. The file /etc/fstab is consulted at boot time for all fiesystems that a Unix compatible system should be aware of. 1) Refer to ConfigMe Page - etc/fstab for configuration instructions. 2) Issue man fstab 3) Additionally, study what the /etc/mtab is for. |