HAMMER1 multi endianness support

[Tomohiro Kusumi]

Thanks for your answer.

> supporting multiple endians creates a pretty big mess.  Its doable, but not really desirable to code-up.

Just asking, but why not really desirable ?

Maybe UFS in various unix don't, but ext2/3/4 use little, and XFS uses big.
Basically all they need is to have tons of host-to-ondisk and
ondisk-to-host, and that's the same with HAMMER.


2016-09-23 20:22 GMT-04:00 Matthew Dillon <dillon at backplane.com>:
> Basically there isn't any support, but the magic number detects which endian
> is in use to ensure that mismatches deny mounts and don't destroy the
> filesystem.  Same with H2.  While it sounds good on paper, supporting
> multiple endians creates a pretty big mess.  Its doable, but not really
> desirable to code-up.  I'm leaving the door open if someone ever wants to
> code it up though.
>
> -Matt
>
> On Fri, Sep 23, 2016 at 4:20 PM, Tomohiro Kusumi <kusumi.tomohiro at gmail.com>
> wrote:
>>
>> This is actually a question to Matt who designed HAMMER1, but what was
>> the original design for HAMMER1's multi endianness support ? I've read
>> a design doc written in 2008, but it didn't have much details to it
>> other than saying we or someone could support both (i.e. support big
>> endian).
>>
>> To be more specific, what's the intention of
>> sys/vfs/hammer/hammer_disk.h having ondisk volume signature macros in
>> both bytes-order ? We currently only use one of them on x86_64, and
>> the other one seems to be there to support both endianness, but how
>> would those two macros be used ?
>>
>> #define HAMMER_FSBUF_VOLUME 0xC8414D4DC5523031ULL /* HAMMER01 */
>> #define HAMMER_FSBUF_VOLUME_REV 0x313052C54D4D41C8ULL /* (reverse endian)
>> */
>>
>> A general and easiest way for a filesystem to support both endianess
>> is to have a fixed ondisk endianness (e.g. little endian for ext2,
>> etc), and make the filesystem code use cpu_to/from_endianness
>> variants, so the code gets compiled with the right conversion to/from
>> the fixed ondisk endianness depending on which ever arch being used.
>> In this case a filesystem doesn't need to have an ondisk field to
>> detect endianness on runtime.
>>
>> DragonFly currently runs only on x86_64, and the filesystem code
>> reads/writes ondisk stuff using host endian, thus ondisk stuff are in
>> little. If someone is to port HAMMER1 to any other OS with support for
>> big endian arch (or ARM port for DragonFly?) can we say HAMMER1 ondisk
>> is in little by design (because the OS that HAMMER1 was originally
>> written for only supported x86, and HAMMER1 simply used host endian) ?
>>
>> or was it intended to do it in an adaptive way like (I think) ZFS ?
>
>