Re: reiserfs empirical study (very long)
On Wed, 30 May 2001, Andrew Sharp wrote:
> The big endian patches change the code to use little endian ordering
> for all on-disk structures. IMO this is a mistake, and certainly
> costs a dear performance penalty, because on big endian processors,
> this method requires converting endianness both ways (reading and
> writing) for all meta data. I submit that there is little reason
> for this, and the performance cost is not worth the very dubious
> feature of having the file system be moveable to little endian
> systems, like x86. Note that except in few cases, the disk labels
We had the same discussion many years ago about ext2fs, and a few years later
about XFS. In fact m68k and ppc used to have a big-endian ext2fs.
Now ext2fs is defined to store metadata in little-endian order, and XFS to
store metadata in big-endian order. This was done for interoperability reasons.
Since people do want to exchange disks between machines, the alternative was to
support both endiannesses. In fact m68k did have a bi-endian ext2fs for a
while, which supported both little and big-endian ext2fs. However, this was
even more costly because all byteswapping decisions had to be made at runtime.
Compare this to the static case, where the compiler can optimize all
byteswapped accesses.
> alone would prevent this. I would very much like to see some endian
> patches that don't have this affect. I believe that the large file
> I/O performance and large directory tree copy performance would show
> a definite increase. It may be too late now.
Until you can prove there's a significant performance difference, I'm afraid
Reiserfs will stay little-endian...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Reply to: