lkml.org 
[lkml]   [1999]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [big performances boost for DataBases] Re: cache killer memory death test - 2.0 vs 2.2 vs arca - programs inside
    From
    Date
    Andrea Arcangeli <andrea@e-mind.com> writes:

    > On 25 Apr 1999, Harvey J. Stein wrote:
    > >
    > >Given that I'm just building the file & exiting, if the kernel behaves
    > >well, then I don't see any reason then to do any gdbm_sync calls at
    > >all. Closing the dbase does an fsync & forces everything to disk
    > >anyway. Why do you think the additional gdbm_sync calls are a good
    > >idea?
    >
    > Closing the DB doesn't do a fsync. That's the whole point. If you do that
    > you'll get data integrity on disk ASAP (instead you won't get better data
    > integrity doing sync in the middle of the proggy if you write to disk
    > after the sync, that's also one of the reason the current buffer.c is
    > broken according to me). But if you need to run the dbase executables many
    > times you can also drop the gdbm_sync before exit.

    Yes it does - I checked the source code before making the claim:

    From gdbm-1.7.3/gdbmclose.c:

    void
    gdbm_close (dbf)
    gdbm_file_info *dbf;
    {
    register int index; /* For freeing the bucket cache. */

    /* Make sure the database is all on disk. */
    if (dbf->read_write == GDBM_WRITER)
    fsync (dbf->desc);

    <snip>

    --
    Harvey J. Stein
    BFM Financial Research
    hjstein@bfr.co.il

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:51    [W:0.042 / U:59.560 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site