Alan Cox wrote: >>> +#define EXOFS_SUPER_ID 0x10000 /* object ID for on-disk superblock */ > > And if an OS failure breaks the super block and you have only one how do > you recover it ? There is nothing really in this object but the "next_id" which is recoverable by an fsck utility (Not yet submitted) by a simple osd-list-partition command. Same for num-of-files. All these values are just cached values, for convenience. > >>> +#define EXOFS_BM_ID 0x10001 /* object ID for ID bitmap */ Not used will be dropped >>> +#define EXOFS_ROOT_ID 0x10002 /* object ID for root directory */ OK Only one, but so is all other directories. I'll think about it. I'll probably postpone it for together with the raid management. >>> +#define EXOFS_TEST_ID 0x10003 /* object ID for test object */ Not used will be dropped > > Ditto some of the others > >>> + EXOFS_UINT64_MAX = (~0LL), >>> + EXOFS_MAX_INO_ID = (sizeof(ino_t) * 8 == 64) ? EXOFS_UINT64_MAX : >>> + (1LL << (sizeof(ino_t) * 8 - 1)), > > Ok so thats quite a big number > >>> + uint32_t s_nextid; /* Highest object ID used */ I fixed all that to be __le64, you can see that on the web here: http://git.open-osd.org/gitweb.cgi?p=open-osd.git;a=shortlog;h=refs/heads/exofs I will submit another round ASAP. I'm currently busy with user-mode-library. Once done I'll post the next exofs round. All these and lots of other areas where converted to proper __leXX types. Specially the directory code had all these missing. It was all triggered thanks to Morton who pointed me to all these ext2 bug-fixes since 2.6.10. > > but that is a smaller one > >>> + uint32_t s_numfiles; /* Number of files on fs */ > > as is this Yes also fixed to __le64 > >>> + uint32_t i_atime; /* Access time */ >>> + uint32_t i_ctime; /* Creation time */ >>> + uint32_t i_mtime; /* Modification time */ > > 2038 ? - bits are cheap > OK Avisi got lazy, This is a copy form ext2. I will fix that, thanks for pointing this out. I will put __le64 for seconds and also add __le64 for nanoseconds while at it. Thanks Ingo for your review Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
