Am Mon, 24 Feb 2014 14:18:17 -0700 schrieb David Boreham <david_list(a)boreham.org>:
> Found out those files is shared mem written to disk!? So moving
it to some
> ram disk seems ridiculous.
If memory gets doubled into a ram disk, then it's ridiculous.
If shared mem and ram disk are shared again, not doubled,
then there's nothing wrong it. That would be ok.
And it seems linux is smart enough to not double it.
Seems /dev/shm uses tmpfs explicitly for mmap().
Ok, then it's not ridiculous. :-)
Now, to get rid of the region and log files you would need to run the
database in a non-transacted mode, or transacted but single-process.
Do you mean with DB_PRIVATE and DB_LOG_IN_MEMORY set to on?
This way I would get rid of all those files (on disk).
I can activate the former one via:
... in /etc/dirsrv/slapd-kolab/dse.ldif
DB_PRIVATE suppresses __db.00* files, that works.
The later one via:
... in /var/lib/dirsrv/slapd-kolab/db/DB_CONFIG
But DB_LOG_IN_MEMORY doesn't work so far. Even if the Database files are
consistent, after a clean shutdown.
Without the database logs (or empty ones) the database won't start:
libdb: file example_com/id2entry.db has LSN 1/3096458, past end of log at 1/140
And with DB_LOG_IN_MEMORY the log is empty with every restart...
I didn't knew those logs are such an important part, and even needed if the
database is in a clean state.
Is there a way to reset LSNs in Database files? That would solve my problem.
If there's no way to reset them, there's no difference in having the log in
ram (DB_LOG_IN_MEMORY) or having the whole database in ram
(/var/lib/dirsrv/slapd-kolab/db/ as tmpfs). If I have to restore the database
on every restart in either case, then it doesn't matter if the database
files itself get lost or are persistent.
Another solution would be some load_log_into_mem_at_startup()- and
save_log_to_disk_on_shutdown()-functions with DB_LOG_IN_MEMORY.
With some kind of a "clean"-flag like there is one in filesystems.
So with a clean shutdown it could be also started very clean.
Then I would only have to recover the database after it has crashed...
(e.g. has the "unclean" flag set)