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 <[email protected]>: > 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 <[email protected]> > 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 ? > >
