> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
