[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
[Linux-cluster] Re: [PATCH 00/14] GFS
- From: Jörn Engel <joern wohnheim fh-wedel de>
- To: David Teigland <teigland redhat com>
- Cc: akpm osdl org, linux-cluster redhat com, linux-kernel vger kernel org, Arjan van de Ven <arjan infradead org>
- Subject: [Linux-cluster] Re: [PATCH 00/14] GFS
- Date: Fri, 5 Aug 2005 12:07:50 +0200
On Fri, 5 August 2005 17:44:52 +0800, David Teigland wrote:
>
> 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.
The function is basically set in stone. Variants exists depending on
how it is called. I know of four variants, but there may be more:
1. Initial value is 0
2. Initial value is 0xffffffff
a) Result is taken as-is
b) Result is XORed with 0xffffffff
Maybe your code implements 1a, while you tried 2b with the lib/crc32.c
function or something similar?
Jörn
--
And spam is a useful source of entropy for /dev/random too!
-- Jasmine Strong
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]