ext2fs: initial support for byteswapping.

[pfg]

Summary

It seems straightforward, although somewhat tedious and error prone, to
search for all the ocurrences of the disk inode fields (e2di_*) and make
sure the filesystem does proper conversion of them to Little Endian.
Most of the action happens in ext2_inode_cnv.c, where some minor
reorganization of the code was done to avoid making multiple conversions.

Test Plan

Extensive testing is required both on Little Endian and Big Endian systems.
It is very easy to get a size mismatch while replacing these or to leave
some missing case. Handle with care.

[fsu]

I am not sure that dinode and superblock conversion will be enough, as I checked on linux side, the group descriptors should be converted too, possible same for bitmaps.
From https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout
"All fields in ext4 are written to disk in little-endian order"

BTW:
Do you know, does the ufs formatted on powerpc will be compatible with Intel?
I mean, if you will format flash drive on powerpc, then insert it to Intel, is it expected that it will be read?

[pfg]

In D23259#510030, @fsu wrote:

I am not sure that dinode and superblock conversion will be enough, as I checked on linux side, the group descriptors should be converted too, possible same for bitmaps.
From https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout
"All fields in ext4 are written to disk in little-endian order"

Yes, everything is in LE. The question is where does the transfer happen? The eraliest we do that, the better. Otherwise we should probably move the group descriptors to the dinode header, to have everything that must be translated in the same place.

BTW:
Do you know, does the ufs formatted on powerpc will be compatible with Intel?

UFS doesn't do byte-swapping: it's a known bug.

I mean, if you will format flash drive on powerpc, then insert it to Intel, is it expected that it will be read?

Nope. There are patches around to do it, but there has been no urgency. I think the policy in UFS would be to have the OS automagically translate either format to the host "sex".
The linux policy is simply to make the fs always LE, and PowerPC is LE on linux anyways.

[pfg]

In D23259#510030, @fsu wrote:

I am not sure that dinode and superblock conversion will be enough, as I checked on linux side, the group descriptors should be converted too, possible same for bitmaps.
From https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout
"All fields in ext4 are written to disk in little-endian order"

Argh .. a look into the NetBSD code indicades the directory entries (atr least e2d_reclen and e2d_namlen) need special treatment as well. Not sure yet about names wichh are character strings.

NetBSD does the gd conversion in ext2fs_alloc.c (ext2fs_cg_update(), ext2fs_cg_get_csum() and ext2fs_init_bb())

[pfg]

Update.
I started modifying htree and lookup as well, but it's coming quickly
off-hand.

I found the following note in a NetBSD commit from 18 Mar 1998:

"Add support for reading/writing FFS in non-native byte order, conditioned
to "options FFS_EI". The superblock and inodes (without blk addr) are
byteswapped at disk read/write time, other metadatas are byteswapped
when used (as they are acceeded directly in the buffer cache).
This required the addition of a "um_flags" field to struct ufsmount.
ffs_bswap.c contains superblock and inode byteswap routines also used
by userland utilities."

In NetBSD ext2 is part of UFS so that is basically their policy for ext2
as well.

[pfg]

Small fix .. and still very far from over.

[pfg]

Sorry I meant to approve this:
https://reviews.freebsd.org/D24685

(fsu should have comandeered this one instead of opening a new one)

[fsu]

In D23259#543509, @pfg wrote:

Sorry I meant to approve this:
https://reviews.freebsd.org/D24685

(fsu should have comandeered this one instead of opening a new one)

I did not managed with new diff uploading, diff did not want to attach to this revision.
Seems like, I can attach diffs only to revisions, which were opened by me.
Please correct me if I am wrong or lose something in the Phabricator UI.

[pfg]

In D23259#543516, @fsu wrote:

In D23259#543509, @pfg wrote:

Sorry I meant to approve this:
https://reviews.freebsd.org/D24685

(fsu should have comandeered this one instead of opening a new one)

I did not managed with new diff uploading, diff did not want to attach to this revision.
Seems like, I can attach diffs only to revisions, which were opened by me.
Please correct me if I am wrong or lose something in the Phabricator UI.

You had to comandeer it in the Action box. You can't do it anymore because it is closed but I know because other people have comandeered my WIP changes ;).

No problem about the new revision though ... Good Job !

[fsu]

In D23259#543519, @pfg wrote:

In D23259#543516, @fsu wrote:

In D23259#543509, @pfg wrote:

Sorry I meant to approve this:
https://reviews.freebsd.org/D24685

(fsu should have comandeered this one instead of opening a new one)

I did not managed with new diff uploading, diff did not want to attach to this revision.
Seems like, I can attach diffs only to revisions, which were opened by me.
Please correct me if I am wrong or lose something in the Phabricator UI.

You had to comandeer it in the Action box. You can't do it anymore because it is closed but I know because other people have comandeered my WIP changes ;).

No problem about the new revision though ... Good Job !

Thanks.
Possible it could be done thru command line tools.
I will try to figure out next time.