🚀 go-pugleaf

In article <mbs.3zdg@adastra.cvl.va.us> mbs@adastra.cvl.va.us (Michael B. Smith) writes:
> In article <dave.06v0@ccomnz.equinox.gen.nz> dave@ccomnz.equinox.gen.nz (David Eaves) writes:
> > > ODU, in and of itself, is not slow unless the lock is contended. What
> > > version of ODU are you running?
> >
> > While on the subject of ODU, how exactly does it handle its file
> > locking?  Does it properly deal with file locking on networked volumes?
> 
> ODU maintains an internal list of locks. It does not communicate with
> a "lockd" on another host, if that's what you mean about networked
> volumes, it's a single host solution.

Bummer, I thought as much.  Can any solution be found that will support
arbitrary networking software?  Does anyone know how Unix handles this?
Using AmigaDOS file/record locking could work with Amiga smart networking
software (such as Envoy), but probably not with TCP/IP NFS because they
wouldn't support the packets.  Correct?

I can only think of creating lock files beside the file to lock
(possible?  Too slow?), or having some kind of replacable lockd back end
that has the smarts for a particular networking software setup.  Any
others?

> > > Actually, the best thing to do is write or use a small syslogd, which
> > > does almost exactly the same thing you are describing here. But what
> > > it means is that only one process owns the file.
> >
> > Can this approach handle multiple log files OK (ie one daemon in charge
> > of multiple log files) acceptably?
> 
> Surely. And at fairly low overhead.
> 
> Actually, though, having a syslogd per file isn't a bunch of overhead
> either. It's almost a trivial application.
> 
> The downside to having multiple files and multiple rendezvous ports
> is then each program has to be a bit smarter about telling a syslogd
> where to put it's output data.
> 
> > > THe downside to this, is if the file isn't closed or flushed after
> > > each write, then you (potentially) loose access to the data.
> >
> > Hmm, that is true.  Anyone got any suggestions on how to deal with
> > this?  Maybee a special logfile device can cater for this explicitly.
> 
> Flush() after each write I/O will take care of properly implemented
> filesystems. It's certainly OK on 3.1 versions of FFS; I can't say
> that I've tested with anything else.
> 
> Flush() _will_ slow it down though.

What say the programs offloaded the writing to a log handling task
which owned the logfile and kept it open?

Would the file be readable by other processes (say if you just want to
look at the logfile) while the lockd has it open for writing though?
Or will the file be opened non-exclusive, and rely on everything being
nice and using the lockd to avoid mixups.

Dave

-- 
.signature under construction