[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: reiserfs empirical study (very long)



Geert Uytterhoeven schrieb:
> 
> On Wed, 30 May 2001, Andrew Sharp wrote:
> > Geert Uytterhoeven wrote:
> > > 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

I can not understand what´s so difficult to put information about the
filesystem in the partition-table?
So i can mark partitions as ext2fs-big or ext2fs-little and the kernel
supports both methods or by a recompile only one of both methods. So
every architecture can read with maximum performance from the filesystem.

I think it is absolutly stupid that x86 rules. They are slower than
Alphas, use more power than PPCs. 
A lot of work at the big-endian front has to be done again, because a
lot of software is or was not endianess-clean, (examples are XMMS,
FireWire-Driver, some other Hardware-Drivers, etc.)

> If the system disk of my PPC box dies, I'll be happy to restore it from backup
> on some other machine...

That´s no problem with the idea above. For restore speed is no need, so
it does not matter if i loose 1% filesystem performance for backups or
repairs. But i think if a linux-box runs low on memory, 1% faster
disk-I/O can make a lot of difference.


That were my 2 Pfennigs, bye,
	Christoph
-- 
Dipl. Ing. Christoph Ewering    C & E Informationsdienste GbR
0 52 54 80 68 66 oder 0173 566 266 1
eweri@cunde.de



Reply to: