🚀 go-pugleaf

In article <mbs.3zs0@adastra.cvl.va.us> mbs@adastra.cvl.va.us (Michael B. Smith) writes:
> In article <dave.06zx@ccomnz.equinox.gen.nz> dave@ccomnz.equinox.gen.nz (David Eaves) writes:

[Bits about ODU and lockd removed]

> > 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?
> 
> Lock files have race conditions, especially across a network. To handle
> it properly is much more difficult than you may think. The locking
> scheme has to be at least bi-level, with a possibility for out-of-band
> data.

Please excuse my ignorance of the technical terms, but what exactly do
"bi-level" and "out-of-band data" mean?  Can they be catered for?  How
easily?

And yes, there is probably a lot more to it than I am aware of :-(

> > > 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?
> 
> Well, I think that's a good idea. I suggested it in another message. ;)

Opps :-)

> > 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?
> 
> It could be. It would take some care in how the file is set up.
> > Or will the file be opened non-exclusive, and rely on everything being
> > nice and using the lockd to avoid mixups.
> 
> Well, you have to do that regardless, to be able to read it. Either that,
> or have a separate review window, which starts getting a bit complicated.

Is logging to be considered a seperate problem from file locking then?
Having a task (logd?) handling log files would avoid the need for
locking logfiles then would it not?  Ideally network support would be
required here also, however.

With a bit of luck we can get somewhere with this thread, even if it
is just to outline the requirements, and perhaps propose "ideal"
solutions.

Dave
-- 
+----------------------------------------------------------------+
 David Eaves, Community Communications, Christchurch, New Zealand
           Phone:  +64-3-3845024,  Fax: +64-3-3841997
           EMail:  dave@ccomnz.equinox.gen.nz
+----------------------------------------------------------------+