Date: 26 Aug 1999 06:59:47 -0000 From: Ville-Pertti Keinonen <will@iki.fi> To: tlambert@primenet.com Cc: wes@softweyr.com, hackers@FreeBSD.ORG Subject: Re: Mandatory locking? Message-ID: <19990826065947.19862.qmail@ns.oeno.com> In-Reply-To: <199908251902.MAA08329@usr08.primenet.com> (message from Terry Lambert on Wed, 25 Aug 1999 19:02:18 %2B0000 (GMT))
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-). I was assuming that mandatory locking, in the context of this discussion, does not mean automatic, forced exclusion on open, but rather explicit locks, applied by calls similar to those used for advisory locking, that are enforced by the kernel. The arguments presented by most people seem to rely on such an interpretation. To avoid confusion, I'll refer to the possible locking methods as advisory locking, explicit locking and implicit locking. > 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. Yes, if file service protocols don't provide locking (or if one of the operating systems involved doesn't provide locking) they obviously can't benefit from any locking that isn't done implicitly. > Also, I believe your example is flawed. If a file is opened by a Not for explicit locking, I hope. > 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. So if a process wishes to use explicit locking calls, it indicates that intent when opening the file - otherwise, the open implicitly locks the file. So multiple writers, or simultaneous readers and writers are only permitted for programs that indicate that they are going to use explicit locks on the file. This could actually make sense. But I don't think that is what is being suggested. > 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. But you certainly don't want to use open/read/write/close cycles for such a purpose. > 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 I think you mean O_EXLOCK. It sets an advisory lock, it does not help against programs that don't use locks. > 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". It doesn't depend on the struct fileops selected, fcntl checks explicitly that f_type is DTYPE_VNODE before assuming that f_data points to a vnode. > For SVR4 semantics, you can set the suid/sgid permission bits on a > non-executable file. The document describing "mandatory" locking in Linux seems to indicate that setting sgid changes the behavior of locking calls to apply explicit locks rather than merely advisory ones, and that this is what is done by other operating systems as well. Actually an implementation could still use the existing (advisory) locks internally, but apply advisory locks in the kernel for the duration of operations that need them (read/write/some cases of open). > 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. I'm fairly certain this is not what is being discussed. Certainly not by more than half of the participants in the discussion. ;--) > Again, there are no issues with badly behaved processes. There > is no such thing as a badly behaved process. I agree, for implicit locks there isn't. 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?19990826065947.19862.qmail>