We even spent time and read the BerkeleyDB source code before we added that feature in GE 2011.11, so just pointing to the man page and say that something is wrong may be too naive. As mentioned by Rayson, we only enabled the DB_PRIVATE flag when there is no need for explict run db_checkpoint or db_archive process operating on the BDB, and that is only when the cluster is not using a BerkeleyDB RPC server for spooling. Other processes do not read or write the Berkeley DB directly, and qmaster is the only one performing I/O against the DB. Long story short, just read the email from Rayson that explains the details at: http://gridengine.org/pipermail/users/2012-May/003683.html
However, I want to raise a bigger problem, and that is the professionalism and work ethics of Dave Love. I believe everyone here who works in a team setting would not expect your teammates or co-workers to ask you for help, then the next day tell everyone in the company how much better he is and why he should take over your job because he knows everything you know, yet he can finish the job in a more efficient way. This was what's happened: we helped Dave who claimed that he wanted to collaborate, and then later on he stabbed our back by saying that the work we shared with him is "definitely not safe": - On the day we release GE 2011.11 (a week before SC11), after we sent the announcement email to the lists, Dave complained about the Univa FUD issue, and he even brought up how it is "obviously a good case for a libel action" during off mailing-list discussions. Then Dave brought up that 2 forks should work together, and Rayson even told people on list and off list about Open Grid Scheduler shareing changes with Dave. - So Dave copied Open Grid Scheduler code into his fork, and during that process Dave *believed* that he found an issue in our code. Instead of letting us know, he deliberately left out that change, and added special flags to work around the problem he *thinks* it is there in Open Grid Scheduler. - And then Dave waits for topics related to Berkeley DB to appear on the list, and then let people know that he found a bug and how his code is supposed to be better. SO, *even if* there is a real issue, when you ask others to share code with you, shouldn't you let the original developers know about the issue first? Hmm, we tried to collaborate with people like this, now eveyone should know why we did not need enemies? -Ron ________________________________ From: William Bryce <[email protected]> To: Dave Love <[email protected]> Cc: [email protected] Sent: Saturday, May 26, 2012 10:40 AM Subject: Re: [gridengine users] maintaining spooldb/sge_job I second what Dave just pointed out below :-) The documentation seems pretty clear to me. Bill. On Sat, May 26, 2012 at 10:12 AM, Dave Love <[email protected]> wrote: Simon Matthews <[email protected]> writes: > >> Some googling on Berkeley DB shows that it is safe for concurrent access by >> different users, so it should be safe to run db_checkpoint without shutting >> down the qmaster. > >That depends. OGS changed the spool handling so that the database is >opened with the DB_PRIVATE flag, which is definitely not safe. See ><http://docs.oracle.com/cd/E17276_01/html/api_reference/C/envopen.html#open_DB_PRIVATE>. >You need the choice so that you can at least do live backups from other >filesystems, as described in ><http://arc.liv.ac.uk/SGE/htmlman/htmlman5/bootstrap.html>, but that's >only in the development version currently. > > >-- >Community Grid Engine: http://arc.liv.ac.uk/SGE/ > >_______________________________________________ >users mailing list >[email protected] >https://gridengine.org/mailman/listinfo/users > _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
