Re: [reiserfs-dev] Re: Ext2 directory index: ALS paper and benchmarks

[Daniel Phillips]

On December 10, 2001 07:27 am, Linus Torvalds wrote:
> On Sun, 9 Dec 2001, Daniel Phillips wrote:
> >
> > Continuing the little warts list, there's Alan's comment re needing endian
> > reversal on big endian machines.
> 
> Now that's a load of bollocks.
> 
> We _already_ keep the in-memory data in "disk format", and for a very
> simple reason: that way we can naturally share all the functions that take
> a pointer to a block tree, and they don't need to care whether the block
> numbers come from a disk buffer or from the inode.

Yes, as the length of an email approaches infinity the chance of saying 
something stupid approaches certainty ;)

> Which means that we have only _one_ set of routines for handling block
> allocation etc, instead of duplicating them all.

I don't know how bad it was in the old code, but now the little-ended data is 
confined to get_block/truncate, as it should be.  However, reading ahead...

> Having in-core data in CPU-native byte order is _stupid_. We used to do
> that, and I winced every time I had to look at all the duplication of
> functions. I think it was early 2.3.x when Ingo did the page cache write
> stuff where I fixed that - the people who had done the original ext2
> endianness patches were just fairly lacking in brains (Hi, Davem ;), and
> didn't realize that keeping inode data in host order was the fundamental
> problem that caused them to have to duplicate all the functions.

I'm not proposing to change this, but I would have chosen Davem's approach in 
this case, with the aid of:

	typedef struct { u32 value; } le_u32;

This is a no-op for Intel, and it would make things nicer for non-intel 
arches, for what that's worth.  But it seems I've stepped into an old 
flamewar, so I'm getting out while my skin is still non-crispy ;)

> So the _wart_ is in 2.2.x, which is just stupid and ugly, and keeps block
> numbers in host data format - which causes no end of trouble. 2.4.x
> doesn't have this problem, and could easily have a pointer to the on-disk
> representation.

Probably what I should have said is that *I* plan to do some conversions 
between on-disk and in-memory format for a patch I'm working on, that it's a 
natural thing to do, and that tying the in-memory inode straight to the disk 
buffer interferes with that.  On the other hand, if the direct pointer really 
is a cache win, it would trump the layering issue.

--
Daniel