> +struct trunk_entry { > + uint64_t oid; > + unsigned char sha1[SHA1_LEN]; > +}; > + > +struct __trunk_entry { > + struct trunk_entry raw; > + int flags; > + struct list_head active_list; > + struct hlist_node hash; > +}; The naming seems a bit unfortunate. It seems like the first one is the on-disk variant, and the second the incore one. Maybe all on-disk structure should get a _disk postfix? Also what about making the disk format endian clean and always using __le or __be types like in the Linux kernel? The same also applies to the on the wire format. > +#define trunk_entry_size() sizeof(struct __trunk_entry) Does this helper really buy you anything? > + > +#define HASH_BITS 10 > +#define HASH_SIZE (1 << HASH_BITS) > + > +static LIST_HEAD(trunk_active_list); /* no lock protection */ > +static struct hlist_head trunk_hashtable[HASH_SIZE]; > +static pthread_mutex_t hashtable_lock[HASH_SIZE] = { [0 ... HASH_SIZE - 1] = PTHREAD_MUTEX_INITIALIZER }; > +static unsigned int trunk_entry_active_nr; Is a hash really a good data structure here? A tree would scale much better with the number of OIDs, which will be very different for different deployments. For example the xfsprogs code has a nice btree library to borrow. > + > +static inline struct __trunk_entry *alloc_trunk_entry(void) > +{ > + return (struct __trunk_entry *)malloc(trunk_entry_size()); > +} No need for the case here. > + struct dirent *d; > + uint64_t oid; > + > + dir = opendir(obj_path); > + if (!dir) > + return -1; > + > + while ((d = readdir(dir))) { > + if (!strncmp(d->d_name, ".", 1)) > + continue; > + oid = strtoull(d->d_name, NULL, 16); > + if (oid == 0) > + continue; You should also check for ULLONG_MAX in case we ended up with a non-numerical entry in the directory for some reason. |