[SCM] CTDB repository - branch tridge created - b616961c16667328a81efa00a1c880efa4e791f1

[Andrew Tridgell]

The branch, tridge has been created
        at  b616961c16667328a81efa00a1c880efa4e791f1 (commit)

- Log -----------------------------------------------------------------
commit b616961c16667328a81efa00a1c880efa4e791f1
Merge: 3e6160e5d90a0661eb833b163c11be2267117d0b 13d3eb9a8bc7fad14fcd3e7e023c1336657424d6
Author: Andrew Tridgell <tridge at samba.org>
Date:   Wed May 14 14:37:11 2008 +1000

    Merge commit 'ronnie-ctdb/master' into tridge

commit 13d3eb9a8bc7fad14fcd3e7e023c1336657424d6
Author: Ronnie Sahlberg <ronniesahlberg at gmail.com>
Date:   Mon May 12 16:44:33 2008 +1000

    When we run the init script to start the ctdb service
    Use tdbdump to verify that all persistent database files are good
    before we start the daemon.

commit 8d6ecf47318188448d934ab76e40da7e4cece67d
Author: Ronnie Sahlberg <ronniesahlberg at gmail.com>
Date:   Mon May 12 13:37:31 2008 +1000

    Try to use tdb transactions when updating a record and record header inside the ctdb daemon.
    
    If a transaction could be started, do safe transaction store when updating the record inside the daemon.
    If the transaction could not be started (maybe another samba process has a lock on the database?) then just do a normal store instead (instead of blocking the ctdb daemon).
    
    The client can "signal" ctdb that updates to this database should, if possible, be done using safe transactions by specifying the TDB_NOSYNC flag when attaching to the database.
    The TDB flags are passed to ctdb in the "srvid" field of the control header when attaching using the CTDB_CONTROL_DB_ATTACH_PERSISTENT.
    
    Currently, samba3.2 does not yet tell ctdbd to handle any persistent databases using safe transactions.
    
    If samba3.2 wants a particular persistent database to be handled using
    safe transactions inside the ctdbd daemon, it should pass
    TDB_NOSYNC as the flags to the call to attach to a persistent database
    in ctdbd_db_attach()     it currently specifies 0 as the srvid

commit 423a2b0965ed6aaaf1dce8864a07ed93944bcf16
Author: Ronnie Sahlberg <ronniesahlberg at gmail.com>
Date:   Mon May 12 07:24:02 2008 +1000

    Update to new release

commit 7c569720beb626617d800211faaf9029f0deb4cf
Author: Ronnie Sahlberg <ronniesahlberg at gmail.com>
Date:   Sun May 11 14:30:43 2008 +1000

    when pulling the nfs directories to check during 60.nfs monitor
    grep for lines starting with a '/' character since exportfs will sometimes
    split a single export line into two lines of output    like this :
    
    [root at fscc-hs21-13 ~]# exportfs
    /NFS4exports/tmp
                    <world>
    /NFS4exports    <world>

commit c4c2c53918da6fb566d6e9cbd6b02e61ae2921e7
Author: Ronnie Sahlberg <ronniesahlberg at gmail.com>
Date:   Sun May 11 14:28:33 2008 +1000

    ctdb->methods becomes NULL when we shutdown the transport.
    
    If we shutdown the transport   and CTDB later decides to send a command out
    for queueing, the call to ctdb->methods->allocate_pkt() will SEGV.
    
    This could trigger for example when we are in the process of shuttind down CTDBD and have already shutdown the transport but we are still waiting for the
    "shutdown" eventscripts to finish.
    If the event scripts now take much much longer to execute for some reason, this
    race condition becomes much more probable.
    
    Decorate all dereferencing of ctdb->methods->    with a check that ctdb->menthods is non-NULL

-----------------------------------------------------------------------


-- 
CTDB repository