File Locking Release Notes

BSD 호환 flock으로의 전환

이 GPL-2.0 문서는 Andy Walker가 1997년 5월 12일 작성한 파일 잠금 release note입니다. 역사적 kernel series에서 `flock(2)` 구현이 어떻게 바뀌었는지와 이후 정책을 기록합니다.

기존 커널의 `flock(2)` emulation은 1.3.x kernel series에서 올바른 BSD 호환 `flock(2)` 지원으로 교체되었습니다. 2.1.x series가 출시되면서 오래된 emulation 지원은 완전히 제거되었고, 더는 그 호환성 부담을 계속 유지하지 않게 되었습니다.

2.1.x kernel 사용자는 적절한 버전으로 C library를 이미 갱신했어야 하므로 이 제거가 사용자에게 문제를 일으키지는 않을 것으로 보았습니다. 관련 요구 버전은 `Documentation/process/changes.rst`를 참고합니다.

.. SPDX-License-Identifier: GPL-2.0

==========================
File Locking Release Notes
==========================

                Andy Walker <andy@lysaker.kvaerner.no>

                            12 May 1997


1. What's New?
==============

1.1 Broken Flock Emulation
--------------------------

The old flock(2) emulation in the kernel was swapped for proper BSD
compatible flock(2) support in the 1.3.x series of kernels. With the
release of the 2.1.x kernel series, support for the old emulation has
been totally removed, so that we don't need to carry this baggage
forever.

This should not cause problems for anybody, since everybody using a
2.1.x kernel should have updated their C library to a suitable version
anyway (see the file "Documentation/process/changes.rst".)

flock과 fcntl 혼용 문제 및 해결

Sendmail은 오래된 `flock()` emulation을 사용할 수 없었기 때문에 Slackware 3.0을 비롯한 많은 설치에서 `flock()` 대신 `fcntl()`을 사용했습니다. Sendmail이 alias 파일을 다시 만들도록 설정된 경우 이 선택이 미묘한 문제를 일으켰습니다.

Sendmail이 `aliases.dir` 파일을 `fcntl()`로 잠그는 동시에 GDBM routine이 같은 파일을 `flock()`으로 잠그려고 했습니다. 1.3.96 이전 kernel에서는 이것이 deadlock으로 이어질 수 있었으며, 시간이 지나거나 mail load가 매우 높을 때 deadlock된 process 때문에 결국 kernel 전체가 멈출 수 있었습니다.

많은 실험과 논의 끝에 채택한 해결책은 `flock()` lock과 `fcntl()` lock이 서로를 전혀 인식하지 않도록 만드는 것이었습니다. 두 방식은 동시에 존재할 수 있지만 어느 쪽도 다른 쪽에 영향을 주지 않습니다.

두 lock 방식을 협력하게 만들고 싶었지만 race와 deadlock 조건이 너무 많아 독립시키는 방법만이 실용적이었습니다. 이는 SunOS 4.1.x와 여러 상용 Unix의 동작과 같습니다. `flock()`과 `fcntl()`을 협력시키는 운영체제는 `fcntl()`로 `flock()`을 emulation하는 계열뿐이며, 그 방식에는 앞서 설명한 문제가 따릅니다.

1.2 Allow Mixed Locks Again
---------------------------

1.2.1 Typical Problems - Sendmail
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Because sendmail was unable to use the old flock() emulation, many sendmail
installations use fcntl() instead of flock(). This is true of Slackware 3.0
for example. This gave rise to some other subtle problems if sendmail was
configured to rebuild the alias file. Sendmail tried to lock the aliases.dir
file with fcntl() at the same time as the GDBM routines tried to lock this
file with flock(). With pre 1.3.96 kernels this could result in deadlocks that,
over time, or under a very heavy mail load, would eventually cause the kernel
to lock solid with deadlocked processes.


1.2.2 The Solution
^^^^^^^^^^^^^^^^^^
The solution I have chosen, after much experimentation and discussion,
is to make flock() and fcntl() locks oblivious to each other. Both can
exists, and neither will have any effect on the other.

I wanted the two lock styles to be cooperative, but there were so many
race and deadlock conditions that the current solution was the only
practical one. It puts us in the same position as, for example, SunOS
4.1.x and several other commercial Unices. The only OS's that support
cooperative flock()/fcntl() are those that emulate flock() using
fcntl(), with all the problems that implies.

Mandatory locking mount option의 폐기

이 release 이전에는 mandatory locking이 모든 mounted filesystem에 유효한 전역 configuration option이었습니다. 이 설계에는 본질적인 위험이 여러 가지 있었습니다.

대표적인 위험은 mandatory lock이 걸린 파일을 NFS server에 읽도록 요청하여 server를 멈출 수 있다는 점입니다. 이러한 mount option은 Kernel v5.14에서 제거되었습니다.

1.3 Mandatory Locking As A Mount Option
---------------------------------------

Mandatory locking was prior to this release a general configuration option
that was valid for all mounted filesystems.  This had a number of inherent
dangers, not the least of which was the ability to freeze an NFS server by
asking it to read a file for which a mandatory lock existed.

Such option was dropped in Kernel v5.14.