On Fri, Jul 11, 2014 at 12:12:22PM -0400, John Wobus wrote: > In cases analogous to this, software often saves both > text and binary, and when initializing, uses mtime to > decide whether it can safely use the binary. Some resources > are spent storing the extra file and admins have yet > another way to screw things up, but the strategy > does have benefits.
You can't always rely on mtime for that. The disk may have been hit by cosmic rays since last time you read the file, and mtime hasn't changed but the file is different anyway. If named had been designed from the beginning with the supposition that it might, at any time, discover that its database was corrupt, and simply stopped serving that particular zone until corrective measures had been taken, then that would be okay. But named is designed to verify its data thoroughly at load time, and then throw an assertion failure if anything looks wrong later. The assumption that the database is reliable, and if it isn't we should crash, runs all through the code; it would be a huge job of work to change it. So with map files, we load the database image with mmap(), then walk down through the tree and verify the checksums. That means the whole database gets paged into physical memory at load time, and that's why map files don't load instantly. Still 3-4 times faster than raw, though. (The idea of keeping both text and map versions of master files around, though -- loading the zone from the map, or else loading from text and creating a new map, depending on mtime -- is definitely under consideration and may turn up in 9.11 if time permits.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
