Date: Wed, 25 Aug 1999 19:02:18 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: will@iki.fi (Ville-Pertti Keinonen) Cc: wes@softweyr.com, hackers@FreeBSD.ORG Subject: Re: Mandatory locking? Message-ID: <199908251902.MAA08329@usr08.primenet.com> In-Reply-To: <86pv0ccfau.fsf@not.demophon.com> from "Ville-Pertti Keinonen" at Aug 25, 99 01:42:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Not to jump down your throat, or anything, but you seem to be
perpetuating some incorrct assumptions about both effect and
proposed implementation details, and they must be stomped. 8-).
> > And how many programmers with nearly (or more than) two decades of UNIX
> > experience it takes to convince someone it really is useful.
>
> It should only take one, as long as the arguments made are not bogus.
>
> IMHO Greg made some very silly arguments (or at least used some very
> stupid examples) for mandatory locking and never answered my points
> regarding them. (The arguments of some of the ones opposing mandatory
> locking have been equally silly.)
I must have missed this...
> I *do* agree that mandatory locking *can* be useful, but the
> usefulness is not nearly as broad as some people seem to be implying,
> and advisory locking is not as useless as some claim.
Advisory locking lacks coherency for a NetWare, SMB, AppleTalk, or
other file server running under FreeBSD as a hosted OS.
It also has the problem that the hosted OS semantics, if they
include mandatory locking, are not enforced against other
processes, e.g. between an SMB server and an AppleTalk server
running on the same machine, or beteen an SMB server and a UNIX
program both needing access to the same database.
> The most significant advantage I see with mandatory locking over
> advisory locking is guaranteeing atomicity for things done by programs
> that do use locking. This only protects the data when programs that
> access the same data without locking don't need locking, which
> generally means that they either don't need to modify the data or that
> there can't be multiple instances of those other programs *and* the
> modifications made are themselves atomic (can't be read-modify-write,
> or even multiple writes if consistency is required).
>
> This is a somewhat limited set of cases. If anyone can come up with a
> counter-example, please present it.
See above.
Also, I believe your example is flawed. If a file is opened by a
process that requires mandatory locking, no process that does not
also open the file with mandatory locking turned on can access the
file. Neither can a program that requires mandatory locking
semantics open the file if it is open by a process not using those
same semantics.
This means that your example applications that "access the same data
without locking" can't exist.
Mandatory locking for things like database files is necessary,
unless the underlying FS supports records (in which case, like
FILES-11, it most likely supports record locking anyway, and
may only decide not to support them if it seperately implements
a transaction facility).
You have to have mandatory locking to implement transactions...
like updating the parity bits on a RAID 5 stripe.
This is why so many _real_ UNIX databases like to squat on their
own raw disk partition.
> Locking entire files, in addition to ranges, would seem to me to be of
> further benefit, as it would allow properly locking programs to fully
> protect against any single non-locking program which, like Greg's cat
> example, would presumably be run interactively and thus would require
> explicit stupidity to create additional races.
This is already possible, using O_EXCL. Likewise, it doesn't
apply to device files, and can not be applied (via fcntl(2)) to
any files whose vnodes indirect through other than the vfsops
version of "struct fileops".
Greg's "cat example", I believe, was intended to illustrate the
example of something which opens and closes the file between
operations. These operations are, themselves, atomic, so in
effect, the mandatory-lock-using program is dealing with a
"snapshot" of the file, as far as it is concerned, with there
being absolutely no danger of a process not obeying the access
protocol running amok during the operation, merely because a
range lock was not asserted.
> Locking entire files is also the only way to ensure that non-locking
> programs can even see the file in a consistent state.
For SVR4 semantics, you can set the suid/sgid permission bits on a
non-executable file.
The act of opening the file for O_RDONLY sets a read lock on the
entire file, which allows multiple readers, and the act of opening
the file O_RDWR sets a write lock on the file, which allows a single
writer.
Again, there are no issues with badly behaved processes. There
is no such thing as a badly behaved process.
For mandatory range locks, you would have to implement a seperate
open mode ("open for mandatory range locking"), and enforce against
writing or reading, which requires modifying the system calls, any
range which was not locked for writing or reading by the process
making the request.
Obviously, one mode could be the setgid bit being set on the file,
and the other the setuid bit, and/or you could define additional
open(2) flags and/or new chflags(1) arguments. The reason SVR4
uses the suid/sgid bits is that SVR4 has no chflags(1), an underlying
FS type may not support chflags(1) attribute bits anyway, use of
additional open(2) flags makes it non-mandatory for some openers
who omit them, and every UNIX FS supports SUID/SGID bits.
In both instances, it's probably wise to state that a blocking
attempt at a write lock (an open without the O_NDELAY flag, for
a file lock, or an attempt to set a lock via the F_SETLKW fcntl(2)
command, for a range lock) would cause blocking attempts at read
locks to queue up behind the write request, rather than completing,
in order to prevent starvation deadlock for writers.
> As a special case, mandatory locking could also be useful in ensuring
> long-term exclusive access to some set of data, but this seems like
> something that should be done using file permissions.
SUID/SGID are stored as part of the file permission bits.
Kind of makes the choice obvious, in retrospect. 8-).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908251902.MAA08329>