SOLARIS
BASICS-P5
FILE
SYSTEM TYPES
Solaris uses VFS (Virtual File System) Architecture. This provides
standard interface for different FS types. It is called VIRTUAL because the user
can issue same command to work regardless of the file system.
SUPPORTED FS TYPES BY VFS:
1. DISK
BASED FS
2. DISTRIBUTED
FS
3. PSEUDO
FS
DISK BASED FS:
It resides on the local disk.
UFS (UNIX FILE SYSTEM): default FS for Solaris
HSFS (HIGH SIERRA FS): Used for CD-ROM and is Read
Only FS
PCFS (PC FILE SYSTEM): Performs R/W operation on DOS
formatted disks. Unix to dos
UDF (UNIVERSAL DISK FORMAT): Technology to store data on
optical media called DVD (digital versatile disk)
DISTRIBUTED FS:
Means not local, scattered/distributed over the network.
Eg. NFS
PSEUDO FS:
These are memory base FS, intended to provide better system
performance. Most Pseudo FS does not use disk space (exception is Cache FS)
Few IMP PSEUDO FS are as follows,
TMPFS (TEMP FS): it uses Phy memory for FS R/W. because of using
Phy memory the R/W operation is anytime faster than UFS. Files in TEMPFS are
not permanent, they are deleted when FS is unmounted or when the system is
rebooted.
TMPFS is default FS type for /tmp directory (if not mounted on Phy
Partition).
bash-3.2# grep tmpfs /etc/vfstab
swap - /tmp
tmpfs - yes
-
We can check it in /etc/vfstab, here it is on system.
If FS type in vfstab is
UFS then disk based, otherwise if
TMPFS then it is memory based
TMPFS doesn’t have fixed size, it grows as it fill.
SWAPFS:
FS used by kernel for swapping
LOFS (LOOPBACK FS):
Provides access to existing FS by using alternate pathname, mainly
used with Zones.
MNTFS:
Maintains info about currently mounted FS, it is R/O FS.
CTFS (CONTRACT FS): CTFS is used by SMF to track
the process which composes some services, so that a failure in multiprocess
service can be identified as a failure of specific service.
/system/contract
DEVFS (DEVICE FS):
Used to manage the devices on the system.
/devices
CACHE FS:
Cache FS let us allow to use local disk to store frequently used data
from a remote FS or CD-ROM.
PROC FS (PROCESS FS):
Running processes, each process on Solaris has a corresponding Dir
under /proc, named with the Process ID of corresponding process. In each dir
there are series of files and subdirectories which contains info about each
process.
All active/running processes are listed in /proc dir by their process
ID.
DIRECTORY
STRUCTURE
/ :- The root of overall file system. The starting directory of unix
directory structure.
/bin :- It contains all the standard system commands like ls, cp, rm
etc.
/dev :-This directory contains logical device names.
/etc :- This directory contains configuration files.
/home :- Home directory for users.
/export :- The default directory for shared file system's. eg;-
User's home directories and other shared file systems.
/kernel :- This contains kernel files that are required as part of
the booting process.
/lib :- The contents of this directory are shared executable files
that are used by many applications at the same time. Library files are part of
executable (these are also executable) so that you don't have to write same
code again and again.
/mnt :- A temporary mount point for external file systems.
/opt :- Directory used for installation of external software's and
applications.
/sbin :- This directory contains files that are used by system during
booting process. it contains system specific commands. The executables in this
directory are very important and are user during system failure.
/usr :- Programs and files or executables available for normal system
users. Basically /usr/bin and /bin are symbolic links to each other.
/var :- Directory for saving system and admin logs. we call it var
directory because it contains files that vary from time and time and by that we
mean log files. All system administration logs are under var directory.
/devices :- the primary directory for physical device names.
/proc :- stores current process related information. all the
processes currently running have directories and subdirectories in this
directory. these directories are named with the PID of the process.
/tmp :- This directory is used to store temporary files. This
directory gets cleared if system is down.
bash-3.2# cd /dev
bash-3.2# find . -type d -print | sed -e 's;[^/]*/;|____;g;s;____|;
|;g'
.
|____dsk
|____fd
|____pts
|____rdsk
|____rmt
|____sad
|____swap
|____term
|____printers
|____cua
|____fbs
|____cfg
|____sound
|____cpu
| |____self
|____md
|____dtrace
| |____provider
|____brand
| |____lx
bash-3.2# cd /opt
bash-3.2# find . -type d -print | sed -e 's;[^/]*/;|____;g;s;____|;
|;g'
.
|____lost+found
|____SUNWits
| |____Graphics-sw
| | |____xil
| | | |____lib
|____SUNWmlib
| |____include
| |____lib
| | |____amd64
| | |____i386
| | |____sse2
|____ocm
| |____bin
|
IMP DIR'S UNDER
ROOT "/" FS
|
|
|
FS
BASED DIR's
|
IN
MEMORY BASED DIR's
|
|
/bin
|
/dev/fd
|
|
/dev
|
/devices
|
|
/etc
|
/etc/mnttab
|
|
/export
|
/etc/svc
|
|
/home
|
/proc
|
|
/kernel
|
/system/contract
|
|
/lib
|
/system/object
|
|
/mnt
|
/tmp
|
|
/opt
|
/var/run
|
|
/platform
|
|
|
/usr
|
|
|
/var
|
|
FS based Dir’s can be controlled by Users. Whereas In Memory Dir’s
are maintained by Kernel and system devices. It is not recommended for users to
interfere with the contents of these directories.
/etc/svc => contains log & reference files related to the
current state of system services.
/var/run => the /tmp and /var/run are by default mounted on top of
swap partition. It means both uses same space as the swap. A memory-based file
system for storing temporary files that are not needed after the system is
booted. /var/run contains system info
data since it was booted.
/run (traditionally /var/run) where privileged daemons can store
runtime data, such as communication primitives. This is where your daemon
should place its sockets. It's guaranteed to be a shared namespace, but is only
writable by privileged code and hence very safe to use. This file system is
guaranteed to be a tmpfs and is hence automatically flushed at boots. No automatic
clean-up is done beyond that. It is machine-private and local. It is
fully-featured, and provides all functionality the local OS can provide
(locking, sockets, ...).
Contents of /var/run
Dr--r--r-- 1 root root 0 Apr 27 23:54 name_service_door
-r--r--r-- 1 root root 4 Apr 27 23:54 powerd.pid
-rw------- 1 root root 0 Apr 27 23:54 ipsecconf.lock
3 unique type of files.
_door FILE:
A door is a special file in Solaris for bidirectional communication between
processes (IPC). Doors provide client processes with a way to call remote code
in a server process and fetch the result.
A door is a special file for inter-process communication between a
client and server, currently implemented only in Solaris.
A door is marked with a D (upper case) as the first letter of the
mode string, e.g.
bash-3.2# pwd
/var/run/
bash-3.2# ls -l *door
Dr--r--r-- 1 daemon daemon 0 Apr 27 23:54 kcfd_door
Dr--r--r-- 1 root root 0 Apr 27 23:54 name_service_door
Dr--r--r-- 1 root root 0 Apr 27 23:54 picld_door
Drw-r--r-- 1 root root 0 Apr 27 23:54 syslog_door
bash-3.2# cd rpc_door
bash-3.2# ls -l
total 0
Drw-r--r-- 1 root root 0 Apr 27 23:54 rpc_100169.1
bash-3.2# cd rpc_100169.1
bash: cd: rpc_100169.1: Not a directory
bash-3.2# file /var/run/picld_door
/var/run/picld_door: door to
picld[158]
bash-3.2# file /var/run/picld_door/*
/var/run/picld_door/*: cannot
open: Not a directory
bash-3.2# file /var/run/rpc_door*
/var/run/rpc_door:
directory
bash-3.2# file /var/run/rpc_door/*
/var/run/rpc_door/rpc_100169.1: door to fmd[579]
Doors are an interprocess communications mechanism. In simple terms,
they're a sort of cross between an RPC service and a Unix domain
socket. Some server (syslogd,
for example) will create a doorfile;
clients of that server are processes on the local machine and connect
to
the door. Connection to the
door (and possibly sending some data to it)
causes the server to run some function which will send information
back
down the door to the client.
A server normally creates a door for some service it plans on
providing, and exports it to clients. Clients who obtain the door may then
invoke the service associated with the door using the synchronous RPC semantics
of a door call operation.
Conceptually, during a door invocation the client thread that issues
the door procedure call migrates to the server process associated with the
door, and starts executing the procedure while in the address space of the
server. When the service procedure is finished, a door return operation is
performed and the thread migrates back to the client's address space with the
results, if any, from the procedure call.
.pid & .lock FILES:
A PID file will contain the Process ID of a running process. This has
various uses; you can read it and check that the process is still running and
take appropriate action or read it and kill the process.
A lock file is most likely application specific. Lock files are used
to indicate that some resource is in use and that the process wanting access
should wait until the resource is freed before continuing.
These files are often used by daemons that should only be run once on
a system. The PID file usually contains the process ID number of the already
launched and running program if one exists. Also, when it starts up, it creates
the lock file. As long as the lock file exists, it won't start another one
without user intervention. If the lock file exists and the process id mentioned
in the pid file isn't running, the daemon is considered to be in a
"dead" state, meaning it's supposed to be running but isn't probably
due to a crash or improper shutdown. This might initiate a special startup /
restart scenario for some programs. Properly shutting it down will remove the
lock file.
References as well as Good read:
No comments:
Post a Comment