NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/unix/wizards/5296

Text File | 1992-12-22 | 4.0 KB | 98 lines

Newsgroups: comp.unix.wizards
Path: sparky!uunet!krfiny!jeffj
From: [e-mail] (J. Jonas)
Subject: Re: /dev/null and file locking
Message-ID: <[e-mail]>
Summary: there are locks, then there are other locks (but no bagles)
Organization: Jeff's house of computer pieces
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 21 Dec 1992 20:25:03 GMT
Lines: 86

In article <[e-mail]> [e-mail] (Barry Margolin) writes:
>In article <[e-mail]> [e-mail] writes:
>>I recall reading in Bach's "The Design of the UNIX Operating System" that
>>device inodes, unlike regular inodes, are never locked.  I don't remember
>>what the rationale was -- perhaps someone more knowledgeable than me could
>>comment.

Okay, let's look at an incore inode
(look at /usr/include/sys/inode.h in system V, or
/usr/include/sys/vnode.h for SUN OS).

For System V, there's a flag bit called ILOCK.
The inode is locked when its being modified, so as to prevent
two (or more) processes from altering the inode at the same time.
This is necessary when adding blocks to a file or anything that's
altering the inode with a complex sequence of operations.
This lock should be very short in span since inode operations
are quite short.
Only the kernel inode manipulation routines may view/alter/test this bit.

There's another lock used for exclusion.
Devices such as line printers don't allow more than one open to succeed.
That lock doesn't seem to reside in the inode, but in a structure
internal to the driver thus the driver is the only thing that may
view/alter/test the bit.
If the lock and status bits are indeed in a driver specific structure,
then it does not matter how many inodes you have going to the same
device (whether it be /dev/null or another), they're all pointing to the
same major/minor number and the same driver using the same
global data structures so there's no chance of confusion.

The File/Record lock is the one that allows processes to battle
for file access privileges with the fcntl/read/write system calls.


If I recall properly, the original question had to do with
making more /dev/nulls on a system.
/dev/null is not an exclusive device and should have no
locking of any sort.  Ignoring data should be a fast operation :-)

There are 3 ways.  In my order of preference:
1) If the desired file is on the same file system as /dev then
make a "hard link" with "ln /dev/null /dev/kr0".
ls -li /dev/null /dev/kr0 shows:
    80 crw-rw-rw-  2 root       3,   2 Dec 18 16:22 /dev/kr0
    80 crw-rw-rw-  2 root       3,   2 Dec 18 16:22 /dev/null

This shows that there are 2 directory entries
both pointing to inode 80 which is a character special device
major number 3, minor number 2.

The nice thing about hard links is that you only create additional
directory entries.  No additional inodes are created.
The 'link count' in the 'ls -l' tells you how many names/directory
entries are pointing to the file.
But how do you find all the names (particularly since they may
be in any directory in the file system)?  'find' them like this:
    find / -inum 80 -mount -print
prints
    /dev/null
    /dev/kr0

(the -mount option tells 'find' to not cross mount points,
because every file system has inodes starting with 2).
[this is due to historical reasons: on a System V file system,
inode 0 means an unallocated/free inode,
inode 1 is reserved for bad blocks
inode 2 is the root directory]

2) If the desired file is not on the same file system,
make a symbolic link as such:
    ln -s /dev/null null2
ls -l shows:
    lrwxrwxrwx  1 jeffj           9 Dec 21 14:59 null2 -> /dev/null


3) If the desired file is not on the same file system as /dev
and the system does not support symbolic links (such as SVR3)
then you have no choice but to make a duplicate character special inode
    /etc/mknod null2 c 3 2
The problem with this is tracking all the inodes pointing to the same
device.  No single find/ncheck/ff will do this.
--
Jeffrey Jonas

[e-mail]