This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deNo matter which mechanism, in general, using a key-value store or having to rewire pointers / struct versions / recover corrupted state could end up being considerable effort: the code would look exactly like asking a DB layer for the data, even if that DB layer is super fast. Is an MSC restart really that common? Restarting the BSC should be fine in that regard, BTW. As soon as it's back, and as soon as the LAC has been associated with that BSC (on the first L3 operation for any subscriber), paging should work out again. We could also add explicit LAC<->point-code mappings in the config to remove that gap, so that the BSC's LACs are known right from the time the BSC is connected. On Fri, Oct 12, 2018 at 11:23:23AM +0200, Michael Andersen wrote: > We use it in MDB_NOSYNC mode. In practice this seems to result in no waiting > for writes in the user thread at any point. so... if LMDB uses disk for pesistent storage, and if you never sync to disk ... how can this possibly work? https://symas.com/understanding-lmdb-database-file-sizes-and-memory-utilization/ explains that LMDB is using memory-mapped files. Elsewhere MDB_NOSYNC is explained to not do fsync() after a commit. So I assume some file system I/O is still happening at some point, but I assume done by the kernel. I have no idea about mem-mapped files, whether that is done blocking. It also says "The memory area occupied by the database file is marked read-only"; so, writing a new entry requires immediate disk I/O? (Or disk I/O cached by the kernel until the next fsync). What if we kept the LMDB db file on a ramdisk? :) (I'm still reluctant to key-value-ize the VLR though.) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20181012/bc4a483f/attachment.bin>