[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Disk format change for trunk's FSFS version 7

From: Branko Čibej <brane_at_wandisco.com>
Date: Mon, 03 Mar 2014 14:20:39 +0100

On 03.03.2014 14:03, Philip Martin wrote:
> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
>
>> On Sun, Mar 2, 2014 at 2:54 AM, Philip Martin <philip.martin_at_wandisco.com>wrote:
>>
>>> There is a problem with the FNV1a checksums in format 7: the on-disk
>>> representation for big-endian systems, like SPARC, is different from
>>> that of little-endian systems, like x86. Both systems calculate the
>>> same checksum value, however the checksum code calls htonl() before
>>> returning the value to the caller. On SPARC this has no effect and on
>>> x86 it reverses the byte order, changing the value. If we were to write
>>> the resulting memory directly to disk as a block of data this would be
>>> good because the disk representations would be the same, but that is not
>>> what happens. The value is passed to encode_uint() which uses arithmetic
>>> to write out a representation of the bytes. Since the htonl() call
>>> changes the x86 value this means the disk representation changes.
>> Committed with a few addition as r1573371 and r1573375.
> This changes the on-disk representation for the unreleased FSFS format 7
> on little-endian systems, that's probably most systems. Anyone with
> repositories in this format needs to dump/load.

That's fine ... it'll teach them not to use unreleased versions. :)

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-03-03 14:21:15 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.