<div dir="ltr">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.<div><br></div><div>-Matt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 23, 2016 at 4:20 PM, Tomohiro Kusumi <span dir="ltr"><<a href="mailto:kusumi.tomohiro@gmail.com" target="_blank">kusumi.tomohiro@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is actually a question to Matt who designed HAMMER1, but what was<br>
the original design for HAMMER1's multi endianness support ? I've read<br>
a design doc written in 2008, but it didn't have much details to it<br>
other than saying we or someone could support both (i.e. support big<br>
endian).<br>
<br>
To be more specific, what's the intention of<br>
sys/vfs/hammer/hammer_disk.h having ondisk volume signature macros in<br>
both bytes-order ? We currently only use one of them on x86_64, and<br>
the other one seems to be there to support both endianness, but how<br>
would those two macros be used ?<br>
<br>
#define HAMMER_FSBUF_VOLUME 0xC8414D4DC5523031ULL /* HAMMER01 */<br>
#define HAMMER_FSBUF_VOLUME_REV 0x313052C54D4D41C8ULL /* (reverse endian) */<br>
<br>
A general and easiest way for a filesystem to support both endianess<br>
is to have a fixed ondisk endianness (e.g. little endian for ext2,<br>
etc), and make the filesystem code use cpu_to/from_endianness<br>
variants, so the code gets compiled with the right conversion to/from<br>
the fixed ondisk endianness depending on which ever arch being used.<br>
In this case a filesystem doesn't need to have an ondisk field to<br>
detect endianness on runtime.<br>
<br>
DragonFly currently runs only on x86_64, and the filesystem code<br>
reads/writes ondisk stuff using host endian, thus ondisk stuff are in<br>
little. If someone is to port HAMMER1 to any other OS with support for<br>
big endian arch (or ARM port for DragonFly?) can we say HAMMER1 ondisk<br>
is in little by design (because the OS that HAMMER1 was originally<br>
written for only supported x86, and HAMMER1 simply used host endian) ?<br>
<br>
or was it intended to do it in an adaptive way like (I think) ZFS ?<br>
</blockquote></div><br></div>