Checkins to OGFS and ODLM

Hi all,

Yesterday, I checked in an update to the OGFS opendlm lock module,
re-working the treatment of LVBs (these were being "forgotten"
prematurely, resulting in an ASSERT regarding a resource groups MAGIC
number), and re-working some alloc/de-alloc of opendlm_lock and LVB
descriptor structures.

Today, I checked in the Computer Associates stability contributions to
the OpenDLM source tree (thanks again for all of that).

The combination seems much more stable.  Mounts/unmounts can now be done
freely on two nodes.  And, no more MAGIC assertions, nor seemingly
random oopses (which were apparently due to alloc/de-alloc anomolies).

Still having some problems, though, when trying to untar then remove the
Linux source tree.  We'll keep at it.  Interestingly enough, things seem
more stable when I'm using a 10 Mbit half-duplex hub, than when I'm
using a 100 Mbit full-duplex router.

Does anyone know why there is *so much LAN traffic* with OpenDLM?  This
doesn't seem right.  It should be more efficient (less traffic) than
memexp, at least when a lock is not immediately available (memexp just
keeps spinning, but OpenDLM should not need to do that, should it?) ....


...  But my LAN LEDs keep lighting up *very actively* long after any
filesystem activity is complete, and it takes longer to do filesystem
stuff with OpenDLM (vs. memexp).  Hmmm, I'm hoping that there's a pretty
serious breach of logic in the OpenDLM code that we can clean up.

-- Ben --


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click