mariadb/storage/bdb/os/os_fid.c
2005-12-05 10:27:46 -08:00

135 lines
4.1 KiB
C

/*-
* See the file LICENSE for redistribution information.
*
* Copyright (c) 1996-2005
* Sleepycat Software. All rights reserved.
*
* $Id: os_fid.c,v 12.4 2005/10/14 15:33:08 bostic Exp $
*/
#include "db_config.h"
#ifndef NO_SYSTEM_INCLUDES
#include <sys/types.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <string.h>
#endif
#include "db_int.h"
/*
* __os_fileid --
* Return a unique identifier for a file. The structure
* of a fileid is: ino(4) dev(4) time(4) pid(4) extra(4).
* For real files, which have a backing inode and device, the first
* 16 bytes are filled in and the extra bytes are left 0. For
* temporary files, the inode and device fields are left blank and
* the extra four bytes are filled in with a random value.
*
* PUBLIC: int __os_fileid __P((DB_ENV *, const char *, int, u_int8_t *));
*/
int
__os_fileid(dbenv, fname, unique_okay, fidp)
DB_ENV *dbenv;
const char *fname;
int unique_okay;
u_int8_t *fidp;
{
pid_t pid;
db_threadid_t tid;
struct stat sb;
size_t i;
int ret;
u_int32_t tmp;
u_int8_t *p;
/* Clear the buffer. */
memset(fidp, 0, DB_FILE_ID_LEN);
/* On POSIX/UNIX, use a dev/inode pair. */
#ifdef HAVE_VXWORKS
RETRY_CHK((stat((char *)fname, &sb)), ret);
#else
RETRY_CHK((stat(fname, &sb)), ret);
#endif
if (ret != 0) {
__db_err(dbenv, "%s: %s", fname, strerror(ret));
return (ret);
}
/*
* !!!
* Nothing is ever big enough -- on Sparc V9, st_ino, st_dev and the
* time_t types are all 8 bytes. As DB_FILE_ID_LEN is only 20 bytes,
* we convert to a (potentially) smaller fixed-size type and use it.
*
* We don't worry about byte sexing or the actual variable sizes.
*
* When this routine is called from the DB access methods, it's only
* called once -- whatever ID is generated when a database is created
* is stored in the database file's metadata, and that is what is
* saved in the mpool region's information to uniquely identify the
* file.
*
* When called from the mpool layer this routine will be called each
* time a new thread of control wants to share the file, which makes
* things tougher. As far as byte sexing goes, since the mpool region
* lives on a single host, there's no issue of that -- the entire
* region is byte sex dependent. As far as variable sizes go, we make
* the simplifying assumption that 32-bit and 64-bit processes will
* get the same 32-bit values if we truncate any returned 64-bit value
* to a 32-bit value. When we're called from the mpool layer, though,
* we need to be careful not to include anything that isn't
* reproducible for a given file, such as the timestamp or serial
* number.
*/
tmp = (u_int32_t)sb.st_ino;
for (p = (u_int8_t *)&tmp, i = sizeof(u_int32_t); i > 0; --i)
*fidp++ = *p++;
tmp = (u_int32_t)sb.st_dev;
for (p = (u_int8_t *)&tmp, i = sizeof(u_int32_t); i > 0; --i)
*fidp++ = *p++;
if (unique_okay) {
static u_int32_t fid_serial = 0;
/* Add in 32-bits of (hopefully) unique number. */
__os_unique_id(dbenv, &tmp);
for (p = (u_int8_t *)&tmp, i = sizeof(u_int32_t); i > 0; --i)
*fidp++ = *p++;
/*
* Initialize/increment the serial number we use to help
* avoid fileid collisions. Note we don't bother with
* locking; it's unpleasant to do from down in here, and
* if we race on this no real harm will be done, since the
* finished fileid has so many other components.
*
* We use the bottom 32-bits of the process ID, hoping they
* are more random than the top 32-bits (should we be on a
* machine with 64-bit process IDs).
*
* We increment by 100000 on each call as a simple way of
* randomizing; simply incrementing seems potentially less
* useful if pids are also simply incremented, since this
* is process-local and we may be one of a set of processes
* starting up. 100000 pushes us out of pid space on most
* 32-bit platforms, and has few interesting properties in
* base 2.
*/
if (fid_serial == 0) {
dbenv->thread_id(dbenv, &pid, &tid);
fid_serial = (u_int32_t)pid;
} else
fid_serial += 100000;
for (p =
(u_int8_t *)&fid_serial, i = sizeof(u_int32_t); i > 0; --i)
*fidp++ = *p++;
}
return (0);
}