| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
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_id70&alloc_id638&opÌk _______________________________________________ Opengfs-devel mailing list Opengfs-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/opengfs-devel