On Fri, Aug 05, 2005 at 09:34:38AM +0200, Arjan van de Ven wrote: > On Fri, 2005-08-05 at 15:14 +0800, David Teigland wrote: > > On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote: > > > > > * +static const uint32_t crc_32_tab[] = ..... > > > why do you duplicate this? The kernel has a perfectly good set of > > > generic crc32 tables/functions just fine > > > > The gfs2_disk_hash() function and the crc table on which it's based are a > > part of gfs2_ondisk.h: the ondisk metadata specification. This is a bit > > unusual since gfs uses a hash table on-disk for its directory structure. > > This header, including the hash function/table, must be included by user > > space programs like fsck that want to decipher a fs, and any change to the > > function or table would effectively make the fs corrupted. Because of > > this I think it's best for gfs to keep it's own copy as part of its ondisk > > format spec. > > for userspace there's libcrc32 as well. If it's *the* bog standard crc32 > I don't see a reason why your "spec" can't just reference that instead. > And esp in the kernel you should just use the in kernel one not your own > regardless; you can assume the in kernel one is optimized and it also > keeps size down. linux/lib/crc32table.h : crc32table_le[] is the same as our crc_32_tab[]. This looks like a standard that's not going to change, as you've said, so including crc32table.h and getting rid of our own table would work fine. Do we go a step beyond this and use say the crc32() function from linux/crc32.h? Is this _function_ as standard and unchanging as the table of crcs? In my tests it doesn't produce the same results as our gfs2_disk_hash() function, even with both using the same crc table. I don't mind adopting a new function and just writing a user space equivalent for the tools if it's a fixed standard. Dave -- Linux-cluster@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/linux-cluster
