Messages in this thread | | | Subject | Re: [big performances boost for DataBases] Re: cache killer memory death test - 2.0 vs 2.2 vs arca - programs inside | From | (Harvey J. Stein) | Date | 26 Apr 1999 01:57:03 +0300 |
| |
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/
| |