🚀 go-pugleaf

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.

> > 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.
--
  //   Michael B. Smith
\X/    mbs@adastra.cvl.va.us