Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | File Locking Release Notes |
2 | ||
3 | Andy Walker <andy@lysaker.kvaerner.no> | |
4 | ||
5 | 12 May 1997 | |
6 | ||
7 | ||
8 | 1. What's New? | |
9 | -------------- | |
10 | ||
11 | 1.1 Broken Flock Emulation | |
12 | -------------------------- | |
13 | ||
14 | The old flock(2) emulation in the kernel was swapped for proper BSD | |
15 | compatible flock(2) support in the 1.3.x series of kernels. With the | |
16 | release of the 2.1.x kernel series, support for the old emulation has | |
17 | been totally removed, so that we don't need to carry this baggage | |
18 | forever. | |
19 | ||
20 | This should not cause problems for anybody, since everybody using a | |
21 | 2.1.x kernel should have updated their C library to a suitable version | |
22 | anyway (see the file "Documentation/Changes".) | |
23 | ||
24 | 1.2 Allow Mixed Locks Again | |
25 | --------------------------- | |
26 | ||
27 | 1.2.1 Typical Problems - Sendmail | |
28 | --------------------------------- | |
29 | Because sendmail was unable to use the old flock() emulation, many sendmail | |
30 | installations use fcntl() instead of flock(). This is true of Slackware 3.0 | |
31 | for example. This gave rise to some other subtle problems if sendmail was | |
32 | configured to rebuild the alias file. Sendmail tried to lock the aliases.dir | |
33 | file with fcntl() at the same time as the GDBM routines tried to lock this | |
34 | file with flock(). With pre 1.3.96 kernels this could result in deadlocks that, | |
35 | over time, or under a very heavy mail load, would eventually cause the kernel | |
36 | to lock solid with deadlocked processes. | |
37 | ||
38 | ||
39 | 1.2.2 The Solution | |
40 | ------------------ | |
41 | The solution I have chosen, after much experimentation and discussion, | |
42 | is to make flock() and fcntl() locks oblivious to each other. Both can | |
43 | exists, and neither will have any effect on the other. | |
44 | ||
45 | I wanted the two lock styles to be cooperative, but there were so many | |
46 | race and deadlock conditions that the current solution was the only | |
47 | practical one. It puts us in the same position as, for example, SunOS | |
48 | 4.1.x and several other commercial Unices. The only OS's that support | |
49 | cooperative flock()/fcntl() are those that emulate flock() using | |
50 | fcntl(), with all the problems that implies. | |
51 | ||
52 | ||
53 | 1.3 Mandatory Locking As A Mount Option | |
54 | --------------------------------------- | |
55 | ||
56 | Mandatory locking, as described in 'Documentation/mandatory.txt' was prior | |
57 | to this release a general configuration option that was valid for all | |
58 | mounted filesystems. This had a number of inherent dangers, not the least | |
59 | of which was the ability to freeze an NFS server by asking it to read a | |
60 | file for which a mandatory lock existed. | |
61 | ||
62 | From this release of the kernel, mandatory locking can be turned on and off | |
63 | on a per-filesystem basis, using the mount options 'mand' and 'nomand'. | |
64 | The default is to disallow mandatory locking. The intention is that | |
65 | mandatory locking only be enabled on a local filesystem as the specific need | |
66 | arises. | |
67 |